1857728 - NS_ERROR_INTERCEPTION_FAILED on vscode.dev

Status: UNCONFIRMED

(Core :: DOM: Service Workers, defect, P3)

Description

[rauchflorian]

Attachment: 2023-10-07 13_44_02.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

Step 1: open https://vscode.dev/

Actual results:

The font can't be loaded due to a NS_ERROR_INTERCEPTION_FAILED error that I can see in the network tab (see screenshot)

Expected results:

The font being loaded just fine (this works in google chrome for example)

Comment 1

[rauchflorian]

some further info:

https://vscode.dev/ is just one example but I've had this some other sites aswell (only other example I can think of is https://open.spotify.com) and it always appears to be related to some service worker issue.

And something interesting I could observe and reproduce is:
Step 1: do a complete fresh Firefox install
Step 2: open https://vscode.dev/ and the font works
Step 3: close Firefox
Step 4: open Firefox again and open https://vscode.dev/ and the font is broken like in the screenshot again

What sucks for me about this issue is that whenever I find a website with a NS_ERROR_INTERCEPTION_FAILED problem then trying to search for a solution is basically not possible, because it seems you just can't resolve the problem yourself unless you made the website yourself.
And at the same time this is never an issue with chrome.

So I'd love that this ominous NS_ERROR_INTERCEPTION_FAILED error is fixed for good or at least there's some easy to understand description on how to deal with this error when you encounter it NS_ERROR_INTERCEPTION_FAILED.

Comment 2

[rauchflorian]

The android documentation site (e.g. https://developer.android.com/codelabs/basic-android-kotlin-compose-first-app) has a similar issue for me, but instead of the NS_ERROR_INTERCEPTION_FAILED I get a 503 status code in the network tab but in the "Transferred" column it says "service worker" so could be related in some distant way
and when I "clear cookies and site data" on that site and refresh and the fonts get loaded just fine because then they aren't loaded through the service worker

maybe this could be a different bug report but also could be soley a server side issue instead of a browser issue
but at the same time why does it work with google chrome's service worker and Firefox service worker is having these issues here?

Comment 3

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

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

Comment 4

[Jens Stutte [:jstutte]]

Attachment: codicon.ttf.loaded.png

I just tried this with Fx118.0.1 release (on Windows), and it seems to work here.

Comment 5

[rauchflorian]

so maybe this has been a me-issue all this time?
how come that it still happens after reinstalling Firefox?
I also tested it with Firefox Beta aswell
what other root causes can this issue have?

Comment 6

[Jens Stutte [:jstutte]]

There might be some interaction between your local environment / settings and our code we would want to investigate.

To rule out the influence of settings in the browser you can go to about:profiles, create a new profile and then click "Launch profile in new browser". If that helps, we know that there is some setting or corruption in your default profile. If that does not help, you can also try to "Restart without add-ons enabled" (always in about:profiles). If that helps, you might want to disable add-ons one by one to find the culprit.

If the problem still persists, you could try to record a debug profile with the firefox profiler (yes, there is a semantic overload here between profile and profile...). Please ensure to choose the "Networking" preset in the profiler settings (which selects also DOM Workers). You can then share that profile via "Upload local profile" which creates a shareable link. Check the privacy settings that pop-up if you are happy with the shared information (in particular screenshots and resource URLs and paths might leak some information if you have other tabs open).

Thanks for your support!

Comment 7

[rauchflorian]

what I tested with about:profiles:

Step 1: create new profile
Step 2: Launch profile in new browser
Step 3: open network tab and filter for fonts
Step 4: open vscode.dev
-> everthing looks fine
Step 5: refresh
-> everything still looks fine (codicon.ttf is cached and not even requested)
Step 6: check "Disable Cache" in network tab
Step 7: refresh again
-> requesting codicon.ttf shows NS_ERROR_INTERCEPTION_FAILED
Step 8: refreshing again with "Disable Cache" unchecked again
-> codicon.ttf remains broken for further requests

Restart without addons:

doesn't resolve the issue and codicon.ttf returns NS_ERROR_INTERCEPTION_FAILED even on the first page load of vscode.dev

Firefox Profiler:

as a test scenario I did the same as in the steps 1-8 above
https://share.firefox.dev/3rTH4tE
I selected to add the screenshots but for some reason they aren't present in the public link, idk why

Comment 8

[Jens Stutte [:jstutte]]

Due to Step6/8 I assume "Network: Cache" is closer, though it might also be Devtools related, of course.

Comment 9

[rauchflorian]

Devtools related I'm not sure, because I can reproduce the issue by replacing the network/disable cache steps with closing and opening the browser (like described in the 4 steps in the first comment)

Caching related? maybe. Possibly a combination of caching and service worker.
But I got no clue about the inner workings of Firefox

Comment 10

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

Jens pinged me and this definitely sounds like a ServiceWorker related problem where the ServiceWorker is throwing an error, so moving back to ServiceWorkers. I couldn't reproduce this on Linux where only "seti.woff" seems to get loaded, but I'll try briefly on Windows. I did see some notes about CORP being applied, so it's possible ORB blocking may be happening or something like that.

Comment 11

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

On windows on Firefox release I saw the codicon.ttf file be fetched successfully.

Thee Firefox profiler run from comment 7 is interesting in that it shows the service worker firing many "unhandledrejection" events.

It would be very interesting to know what some of these errors are, especially related to fetch requests.

Reporter, could you

• Open a tab with the debugger attached to the ServiceWorker:
  • open about:debugging#/runtime/this-firefox
  • expand "service workers"
  • use ctrl-f / find-in-page to locate the "vscode.dev" service worker
  • click the "inspect" button
  • Now you should be able to see any errors reported inside the ServiceWorker.
• Open vscode.dev and verify the problem you're seeing happens
• Go back to the debugger attached to the service worker and see what it said

The SW should retain any messages already logged since it started up, so attaching to it after you reproduce the problem can be fine except that the ServiceWorker gets automatically shut down after a delay, so it's possible that if you don't attach before it gets shutdown, the error messages may get lost. Also, I think devtools should be trying to keep the ServiceWorker alive with a debugger attached, but something does seem to be going wrong and that's not happening. If you have problems getting the data you can change the "dom.serviceWorkers.idle_extended_timeout" and "dom.serviceWorkers.idle_timeout" from 30,000 (30 seconds) to a higher value, but you will want to reset them later on as you don't want all ServiceWorkers being able to experience this.

Comment 12

[rauchflorian]

Attachment: service-worker-log.png

ok I checked via about:debugging but the service worker output looks "normal" from what I can tell

Comment 13

[rauchflorian]

Attachment: console-log.png

but I noticed something else now
When searching for "ttf" in the console log I see a bunch of requests regarding CORS

Which brings up 2 questions for me:

• Why are these CORS errors not happening in e.g. google chrome?
• Why is it not visible that loading the font fails because of CORS in the network tab? (from what I remember usually it says "Blocked by CORS" also in the network tab but I'm not 100% sure anymore - at least that would be more obvious of an error message in my opinion though)

Comment 14

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

(In reply to rauchflorian from comment #13)

but I noticed something else now
When searching for "ttf" in the console log I see a bunch of requests regarding CORS

Aha! Thank you! This seems like it's likely to be the problem. Because of how interception works, it's quite possible that the CORS error is being transformed into an interception failure when maybe we instead should be propagating certain classes of errors.

The underlying error is perhaps one of:

• Bug 1189945
• CSS-related which could propagate into the font, perhaps: Bug 1467454 and Bug 1467998

Joshua, I think this might make sense for you to look at especially based on some of the prior investigations you've done relative to range requests, etc. Setting needinfo.

Comment 15

[rauchflorian]

Attachment: open-spotify-and-tinder.png

I just checked with 2 other sites I had issues with (open.spotify.com and tinder.com)
and they have the same CORS erros in the console logs aswell

Comment 16

[Eden Chuang[:edenchuang]]

I guess this might be related to the principal of FetchEvent.request.

In the ServiceWorker script, using FetchEvent.request sometimes will have a different result from using a copied request.
Considering the following case, res1 and res2 could have different results.

self.onfetch = (event) => {
   let res1 = fetch(event.request);
   let copyRequest = event.request;
   let res2 = fetch(copyRequest);
}

This is because the triggering principal of event.request should be from the original (intercepted) page, but the copied request's triggering principal is ServiceWorker.

Comment 17

[rauchflorian]

Hey all,

I did a fresh install of windows 11 yesterday and as I expected it, it did fix this bug for me
I'm still confused how this bug appeard for me in the first place even after reinstalling firefox and other versions of firefox, but I guess it will be near impossible to find out the reason now
from my point of view this ticket can be closed, so feel free to close it if you have the same view on this
no idea if anyone else has experienced this bug at some point but if someone reports a similar bug in the future then I guess this ticket can be reopened or referenced then

Thanks for looking into this