2029029 - CSS request fails, but should be intercepted by service worker

Status: ASSIGNED

(Core :: DOM: Service Workers, defect)

Description

[Christopher Cooper]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:149.0) Gecko/20100101 Firefox/149.0

Steps to reproduce:

Tested Firefox 149 (broken) and Firefox 148 (works) on Arch Linux, as packaged by the OS. (Originally observed in Zen Browser 1.19.5b, and bug submitted from Zen. But tested with Firefox.)

Steps:

1. Install code-server (https://github.com/coder/code-server)
2. Run code-server, connect to UI
3. Open or create a markdown file in the UI, then press ctrl+shift+V to open the markdown preview.

Actual results:

The markdown preview is unstyled. The stylesheet does not load correctly. In the network tab, observe that markdown.css was blocked.

await fetch("https://vscode-remote+127-002e0-002e0-002e1-003a8080.vscode-resource.vscode-cdn.net/usr/lib/code-server/lib/vscode/extensions/github/markdown.css", {
    "credentials": "omit",
    "headers": {
        "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:149.0) Gecko/20100101 Firefox/149.0",
        "Accept": "text/css,*/*;q=0.1",
        "Accept-Language": "en-US,en;q=0.9",
        "Sec-Fetch-Storage-Access": "none",
        "Sec-GPC": "1",
        "Sec-Fetch-Dest": "style",
        "Sec-Fetch-Mode": "no-cors",
        "Sec-Fetch-Site": "cross-site",
        "Priority": "u=2"
    },
    "referrer": "http://127.0.0.1:8080/",
    "method": "GET",
    "mode": "cors"
});

{
	"An error occurred:": "SSL_ERROR_BAD_CERT_DOMAIN"
}

Expected results:

A stylesheet should be loaded and applied to the markdown. In network tab, markdown.css should be loaded with 200.
This is the actual result on Firefox 148, but not on 149.

await fetch("https://vscode-remote+127-002e0-002e0-002e1-003a8080.vscode-resource.vscode-cdn.net/usr/lib/code-server/lib/vscode/extensions/github/markdown.css", {
    "credentials": "omit",
    "headers": {
        "User-Agent": "Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0",
        "Accept": "text/css,*/*;q=0.1",
        "Accept-Language": "en-US,en;q=0.9",
        "Sec-Fetch-Storage-Access": "none",
        "Sec-Fetch-Dest": "style",
        "Sec-Fetch-Mode": "no-cors",
        "Sec-Fetch-Site": "cross-site"
    },
    "referrer": "http://127.0.0.1:8080/",
    "method": "GET",
    "mode": "cors"
});

Note there are no Sec-Fetch-Storage-Access, Sec-GPC, or Priority headers.
The response has status code 200.

Comment 1

[Christopher Cooper]

I also observed that other requests to this fake hostname that are not CSS files seem to succeed. Breakpoints in the service worker are hit. However for CSS files, the request doesn't seem to even reach the service worker and breakpoints are never hit.

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Peter Lu [:Mr-Sheep]]

Can confirm this issue.

We are running a coder/code-server session in FF 149.0 and observed that synthetic resource URLs of the form https://vscode-remote+<encoded-host>.vscode-resource.vscode-cdn.net/... (which are expected to be intercepted by a service worker and resolved locally) are not consistently intercepted (js worked fine, but not css)

Instead, Firefox attempts to treat the request as a normal network fetch and fails with NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_SECURITY, SSL_ERROR_BAD_CERT_DOMAIN).

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Hmm, can you run mozregression to see when it broke?

Something like:

mozregression --good 148 --bad 149

Or so.

Comment 5

[Christopher Cooper]

mozregression result:

 8:28.26 INFO: Narrowed integration regression window from [ff199b24, c39b976a] (4 builds) to [fe838ff6, c39b976a] (2 builds) (~1 steps left)
 8:28.26 INFO: No more integration revisions, bisection finished.
 8:28.26 INFO: Last good revision: fe838ff6e2c25e79bddf90603e980df652306b7c
 8:28.26 INFO: First bad revision: c39b976ade75d9020c2937af1027b8a0af3c81c0
 8:28.26 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fe838ff6e2c25e79bddf90603e980df652306b7c&tochange=c39b976ade75d9020c2937af1027b8a0af3c81c0

Comment 6

[Christopher Cooper]

Looking at the bug linked to that revision (https://bugzilla.mozilla.org/show_bug.cgi?id=1201160), it seems this may be intentional. (Don't fully understand the context.) However, I'll note that this particular application does still work in Chromium.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Eden, mind taking a look?

Comment 8

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

Set release status flags based on info from the regressing bug 1201160

Comment 9

[Ben Wells]

This has broken our offline experience in latest Firefox, which we're trying to fix. Note it only breaks on Firefox - chromium and safari still work.

I'm confused about the change. The linked bug describes the change needed as:

To be clear, what needs to be done here is that any resources fetched from a stylesheet, that was itself fetched using "no-cors" and is cross-origin (not sure about cross-origin with redirect to same-origin), need to skip the service worker.

But the actual code change seems to be doing more than that:

Skip ServiceWorker interception for no_cors subresource fetching from CSS

• RequestDestination requestDest =

•    InternalRequest::MapContentPolicyTypeToRequestDestination(
  

•        loadInfo->GetExternalContentPolicyType());
  

• // Skip no_cors Cross-Origin sub-resource request from CSS.
• if (requestMode == RequestMode::No_cors &&

•    requestDest == RequestDestination::Style) {
  

•  nsCOMPtr<nsIPrincipal> triggeringPrincipal;
  

•  (void)loadInfo->GetTriggeringPrincipal(
  

•      getter_AddRefs(triggeringPrincipal));
  

•  MOZ_ASSERT(triggeringPrincipal);
  

•  bool mayLoad = nsContentUtils::CheckMayLoad(
  

•      triggeringPrincipal, aChannel, /*allowIfInheritsPrincipal*/ false);
  

•  if (!mayLoad) {
  

•    *aShouldIntercept = false;
  

•  }
  

• }

i.e. it blocks the SW from seeing all non-cors CSS changes. Was that intentional?

Either way if we could get more details on exactly how to fix this it would be super helpful

Comment 10

[Emilio Cobos Álvarez [:emilio]]

Andrew maybe you can provide more context?

Comment 11

[Ben Wells]

A small update: we figured out we just need to add crossOrigin: "anonymous" attribute to our CSS links, but it's too risky to do at this time as it will impact all browsers and is deep in our webpack plugin code and base html templates.

FWIW, our code worked in Safari so the comments on the bug about becoming inline with Safari don't ring true. Firefox is the only browser we have this problem with.