Still having service worker refresh problems

[domenic]

Rarely, usually never more than once per computer, I get the following errors:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://resources.whatwg.org/standard.css. (Reason: CORS request did not succeed).[Learn More]

Failed to load ‘https://resources.whatwg.org/standard.css’. A ServiceWorker passed an opaque Response to FetchEvent.respondWith() while handling a ‘cors’ FetchEvent. Opaque Response objects are only valid when the RequestMode is ‘no-cors’. standard-service-worker.js:47:4

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://resources.whatwg.org/standard-shared-with-dev.css. (Reason: CORS request did not succeed).[Learn More]

Failed to load ‘https://resources.whatwg.org/standard-shared-with-dev.css’. A ServiceWorker passed an opaque Response to FetchEvent.respondWith() while handling a ‘cors’ FetchEvent. Opaque Response objects are only valid when the RequestMode is ‘no-cors’. standard-service-worker.js:47:4

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://resources.whatwg.org/logo-fetch.svg. (Reason: CORS request did not succeed).[Learn More]

I'll try to look into what could be going wrong here.

[domenic]

The symptoms seem the same as https://github.com/whatwg/streams/issues/955 but I'm unsure how this could possibly be happening, at least via code inspection.

[annevk]

I can reproduce this in Firefox refreshing https://streams.spec.whatwg.org/:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://resources.whatwg.org/logo-streams.svg. (Reason: CORS request did not succeed).

for the SVG logo. I wonder if this is due to preloading not taking crossorigin into account and therefore getting a cache mismatch or some such, but somewhat grasping at straws.

@asutherland something you might wanna look at?

[domenic]

You're right, I can consistently reproduce this on Firefox with logos. But I even saw it once for the stylesheets again while testing today. And for those, it disappeared after the first attempt.

[asutherland]

I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1551557 to track any Firefox specific implementation issues and our investigation of this. We'll be sure to chime back in here for any spec-related things and/or once we understand what's happening in Firefox.

[domenic]

This is happening often enough in Firefox for me (but also Chrome) that I'm contemplating removing our service worker. It just seems embarrassing to end up with a completely unstyled spec for what, in my experience, is about ~1/10 visits. (Especially if, as I suspect, the problem occurs more often for empty caches, i.e. first-time visitors.)

To be clear, the issue appears to be with:

• <link rel="stylesheet|icon" crossorigin="">
  • icon triggers fairly reproducibly (~4/5 times) in Firefox only
  • stylesheet triggers much less often; my best guess is it happens when I haven't visited the site in a while, but private browsing mode/incognito is not guaranteed to reproduce
  • I have never seen this error for the <script crossorigin=""> resources.
• A cache-then-network strategy, which you can see at https://github.com/whatwg/whatwg.org/blob/86220b18cf23b984fdac4db52ac006ce0fe5d00e/resources.whatwg.org/standard-service-worker.js#L46-L63
• Firefox's console says that the reason for the failure is that respondWith() is being passed an opaque response. I don't see how this is possible, given the crossorigin="" attribute. (I believe the same is true for Chrome but I don't remember the error message precisely.)
  • @annevk's guess above is plausible at least? I'm surprised nobody else has reported it before though, if that's the case. Maybe nobody else uses crossorigin="" on their <link>s?

[wanderview]

Does this mainly happen when devtools is open? I think sometimes devtools can make additional requests that could have unexpected modes.

[domenic]

Nope, I only see these errors after popping open the console. This happens when I just visit the website normally trying to look at specs :(.

I like @annevk's latest hypothesis that HTML doesn't use crossorigin="" for everything the other specs do and this causes some wierd caching issue...

[andreubotella]

With bug 1661075 fixed, the logos are now showing up on Firefox Nightly. Note that this fix wasn't related to preload at all, it just changed <link rel=icon> to support the crossorigin attribute, so if the preload scanner is indeed preloading icons, the failure rate might've merely dropped significantly rather than completely disappearing.