1618546 - Blank page is displayed when inspecting some pages from Service workers

Status: RESOLVED FIXED

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

Description

[Mihai Boldan, Desktop QA [:mboldan]]

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

• This issue is reproducible only on a few websites.
  • https://www.facebook.com/
  • https://app.starbucks.com/

Comment 1

[Andrew Overholt [:overholt]]

Is this the same as bug 1611081?

Comment 2

[Mihai Boldan, Desktop QA [:mboldan]]

(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.

Comment 3

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

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

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

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?

Comment 5

[Jens Stutte [:jstutte]]

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

Comment 6

[:Harald Kirschner :digitarald]

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.

Comment 7

[Julian Descottes [:jdescottes]]

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:

• https://searchfox.org/mozilla-central/source/devtools/server/startup/worker.js#37
• https://searchfox.org/mozilla-central/source/dom/webidl/WorkerDebuggerGlobalScope.webidl#15
• https://searchfox.org/mozilla-central/source/dom/workers/WorkerScope.cpp#1013
• https://searchfox.org/mozilla-central/source/dom/workers/ScriptLoader.cpp#2353

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.

Comment 8

[Julian Descottes [:jdescottes]]

Attachment: Bug 1618546 - WIP: Fix worker debugging for service workers using a CSP

Comment 9

[Julian Descottes [: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.

Comment 10

[:Harald Kirschner :digitarald]

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.

Comment 11

[Perry Jiang [:perry] [no longer employee, use ni?]]

Taking a look!

Comment 13

[Perry Jiang [:perry] [no longer employee, use ni?]]

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

Comment 14

[Jens Stutte [:jstutte]]

Perry, can you come to this soon? Thanks!

Comment 15

[Perry Jiang [:perry] [no longer employee, use ni?]]

Yep, on this now.

Comment 16

[Perry Jiang [:perry] [no longer employee, use ni?]]

Attachment: Bug 1618546 - give worker debugger globals their own clients r?asuth

• 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

Comment 17

[Jens Stutte [:jstutte]]

Hi Perry, can/should we land this?

Comment 18

[Perry Jiang [:perry] [no longer employee, use ni?]]

Fixed small review comment, landing now.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2fd61eb5c69c
give worker debugger globals their own clients r=asuth,webidl,smaug

Comment 20

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/2fd61eb5c69c

Comment 22

[Julian Descottes [:jdescottes]]

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 :)

Comment 23

[Peter Magyari (Desktop QA)]

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

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

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