Closed Bug 1618546 Opened 4 years ago Closed 4 years ago

Blank page is displayed when inspecting some pages from Service workers

Categories

(DevTools :: about:debugging, defect, P2)

Desktop
All
defect

Tracking

(firefox-esr68 unaffected, firefox73 unaffected, firefox74 wontfix, firefox75 wontfix, firefox76 wontfix, firefox77 verified)

RESOLVED FIXED
Firefox 77
Tracking Status
firefox-esr68 --- unaffected
firefox73 --- unaffected
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- verified

People

(Reporter: mboldan, Assigned: perry)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Crash Data

Attachments

(1 file, 1 obsolete file)

Affected versions

  • Firefox 74.0b8
  • Firefox 75.0a1

Affected platforms

  • Windows 10x64
  • macOS 10.15
  • Ubuntu 18.04 x64

Steps to reproduce

  1. Launch Firefox.
  2. Access https://www.twitter.com and allow 'Send notifications' option.
  3. Go to 'This Firefox' from about:debugging.
  4. Click 'Inspect' option.

Expected result

  • A new tab is displayed, with the Console opened.

Actual result

  • A blank page is displayed.

Regression range

  • Will investigate ASAP.

Additional notes

Has Regression Range: --- → no
Has STR: --- → yes

Is this the same as bug 1611081?

(In reply to Andrew Overholt [:overholt] (returning March 6th) from comment #1)

Is this the same as bug 1611081?

From my opinion this bugs are different, since the bug logged by me is service workers specific and the blank page is displayed from the start and not after refreshing the page.

Priority: -- → P2

Hello ,

I have returned with a regression range:

First good: 2019-11-24
First bad: 2020-02-27
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e19228b7fd46c2adfb97d00aca2033f6e3503ccf&tochange=39994d0c291b1557e5de189d476d0b00a515b4c0

Potential regressor: 1586411

Has Regression Range: no → yes

Going to move this to about:debugging for now since from comment 0 it sounds like the the devtools console pane isn't being displayed, suggesting something might be happening in the handoff from about:debugging?

Component: DOM: Service Workers → about:debugging
Product: Core → DevTools

Hi Julian, can someone get to this? Thank you!

Flags: needinfo?(jdescottes)

Logs from the first attempt (they don't show up on second tries):

<empty string>
Content Security Policy: The page’s settings blocked the loading of a resource at resource://devtools/shared/worker/loader.js (“script-src”). 2
NetworkError: WorkerDebuggerGlobalScope.loadSubScript: Failed to load worker script at resource://devtools/shared/worker/loader.js (nsresult = 0x805e0006) worker.js:37
XrayWrapper denied access to property "wrappedJSObject" (reason: value shadows a property on the standard prototype). See https://developer.mozilla.org/en-US/docs/Xray_vision for more information. Note that only the first denied property access from a given global object will be reported. utils.js:69:24
NetworkError: WorkerDebuggerGlobalScope.loadSubScript: Failed to load worker script at resource://devtools/shared/worker/loader.js (nsresult = 0x805e0006)

This works fine with service-worker debugging (devtools.debugger.features.windowless-service-workers) on, so bug 1603190 might also fix this.

This looks like a CSP issue.
The error is 0x805e0006 -> NS_ERROR_CONTENT_BLOCKED.

It comes from the following spot https://searchfox.org/mozilla-central/rev/7d0c94a0e9a9fe1f83553f49b10128567d21709d/dom/security/nsContentSecurityManager.cpp#593
The reason we go into the if block is because NS_CP_REJECTED(shouldLoad) is true, so that means NS_CheckContentLoadPolicy rejected the load.

(note: I have been using https://app.starbucks.com/ to test this, because it doesn't require signing in to anything to install the service worker).

If I log the policy which led to rejecting the script load, it is:

default-src 'self' https://.starbucks.com https://.starbucksassets.com; child-src 'self' https://.starbucks.com https://.americanexpress.com https://.chase.com https://.doubleclick.net https://.facebook.com https://.mastercard.com https://masterpass.com https://.masterpass.com https://.optimizely.com https://.paypal.com https://.visa.com; connect-src 'self' ws: https://.starbucks.com https://.starbucksassets.com https://.akamaihd.net https://.akstat.io https://.doubleclick.net https://.facebook.com https://.go-mpulse.net https://.google-analytics.com https://.iesnare.com wss://mpsnare.iesnare.com https://.mastercard.com https://.mparticle.com https://.nr-data.net https://.optimizely.com https://.paypal.com https://thm.visa.com https://.zeronaught.com; font-src 'self' data: https://.starbucks.com https://.starbucksassets.com https://fonts.gstatic.com; img-src 'self' data: https://.starbucks.com https://.starbucksassets.com https://.adsrvr.org https://.agkn.com https://.akamaihd.net https://.bing.com https://.demdex.net https://.doubleclick.net https://.facebook.com https://.google.com https://.google-analytics.com https://.googleapis.com https://.googletagmanager.com https://.gstatic.com https://.marinsm.com https://masterpass.com https://.masterpass.com https://.mparticle.com https://.nr-data.net https://bs.serving-sys.com https://.visa.com; media-src 'self' data: https://.starbucks.com https://.starbucksassets.com https://.iesnare.com; object-src 'self' https://.starbucks.com https://thm.visa.com; script-src 'self' 'unsafe-eval' 'unsafe-inline' https://.starbucks.com https://.starbucksassets.com https://.aexp-static.com https://s3.amazonaws.com https://.akamaihd.net https://.bing.com https://.chase.com https://.doubleclick.net https://.facebook.net https://.go-mpulse.net https://.google.com https://.google-analytics.com https://.googleadservices.com https://.googleapis.com https://.googletagmanager.com https://.iesnare.com https://.mastercard.com https://masterpass.com https://.masterpass.com https://.mparticle.com https://.newrelic.com https://.nr-data.net https://.optimizely.com https://.paypal.com https://.visa.com; style-src 'self' 'unsafe-inline' https://.starbucks.com https://.starbucksassets.com https://.google.com https://fonts.googleapis.com; report-uri https://app.starbucks.com/webhooks/csp-report

This CSP is defined in the response headers of every response coming from https://app.starbucks.com/

On the other hand, if we look at the origin of the load:

So I think we end up calling ScriptLoader::Load, and this fails. But interestingly, we have already loaded a script in this worker, because server/startup/worker.js already runs in the worker thread. The difference is that this is "main script" and it was loaded via ScriptLoader::LoadMainScript.

Trying to understand the differences between a regular "DebuggerScript" script and a "main" script, I tried replacing a few "is main script" checks by "is main script or is debugger script". Changing the following one in LoadAllScripts seems to do the trick: https://searchfox.org/mozilla-central/rev/7d0c94a0e9a9fe1f83553f49b10128567d21709d/dom/workers/ScriptLoader.cpp#2212

  if (!aIsMainScript) {
    clientInfo = aWorkerPrivate->GetClientInfo();
    controller = aWorkerPrivate->GetController();
  }

But I'm of course missing context on the potential implications of such a change.

(In reply to :Harald Kirschner :digitarald from comment #6)

Logs from the first attempt (they don't show up on second tries):

This works fine with service-worker debugging (devtools.debugger.features.windowless-service-workers) on, so bug 1603190 might also fix this.

It wouldn't fix the issue here, it would provide a workaround. The feature would still be broken in about:debugging.

Flags: needinfo?(jdescottes)

Hi Perry, could you take a look at https://phabricator.services.mozilla.com/D66553 ?
The regular "DebuggerScript" we try to load when debugging service workers bounces when a CSP is defined.
The patch attached here fixes the issue, but I don't really know if this is the correct approach.

Flags: needinfo?(perry)

It wouldn't fix the issue here, it would provide a workaround. The feature would still be broken in about:debugging.

To clarify: The issue wasn't reproducible in about:debugging with the sw debugging pref on. But looking at your analysis, maybe this was just a fluke.

See Also: → 1622429

Taking a look!

Flags: needinfo?(perry)

It was decided that most of the work would probably be on the worker implementation side

Assignee: nobody → perry
Attachment #9132835 - Attachment is obsolete: true

Perry, can you come to this soon? Thanks!

Flags: needinfo?(perry)
Status: NEW → ASSIGNED

Yep, on this now.

Flags: needinfo?(perry)
  • Worker debugger globals gets a client with a null principal
  • Introduce WorkerGlobalScopeBase to share code
  • Transfer ClientSource ownership from WorkerPrivate to worker globals
  • Require getting clients from the globals instead of WorkerPrivate with the
    exception of getting the reserved client before the non-debugger global is
    created

Hi Perry, can/should we land this?

Flags: needinfo?(perry)

Fixed small review comment, landing now.

Flags: needinfo?(perry)
Pushed by pjiang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2fd61eb5c69c
give worker debugger globals their own clients r=asuth,webidl,smaug
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 77

Thanks a lot for working on this :perry and :asuth!
Looks like this issue was actually breaking more toolboxes than just Service Worker ones, so your fix is really a life saver here :)

Verified fixed on Windows 10 and MacOS 10.15 using Firefox 77.0a1 (20200421222503)

Crash Signature: [@ mozilla::dom::ClientSource::MaybeCreateInitialDocument()] [@ mozilla::dom::ClientSource::SnapshotState()] [@ mozilla::dom::ClientSource::SnapshotState(mozilla::dom::ClientState*)]

The patch landed in nightly and beta is affected.
:perry, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(perry)

We're building the 76 RC today. Let's let this bake a bit more and ride 77 to release.

Crash Signature: [@ mozilla::dom::ClientSource::MaybeCreateInitialDocument()] [@ mozilla::dom::ClientSource::SnapshotState()] [@ mozilla::dom::ClientSource::SnapshotState(mozilla::dom::ClientState*)] → [@ mozilla::dom::ClientSource::MaybeCreateInitialDocument()] [@ mozilla::dom::ClientSource::SnapshotState()] [@ mozilla::dom::ClientSource::SnapshotState(mozilla::dom::ClientState*)]
Flags: needinfo?(perry)
Regressions: 1632036
You need to log in before you can comment on or make changes to this bug.