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 whatwg/streams#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

  whatwg.org/resources.whatwg.org/standard-service-worker.js

  Lines 46 to 63 in 86220b1

  	// For auxiliary resources, we can use a cache-then-network strategy; it is OK to not get the freshest.
  	e.respondWith(
  	caches.match(e.request, { cacheName: cacheKey }).then(cachedResponse => {
  	const networkFetchPromise = fetch(e.request);
  	// Only warn on network fetch or caching errors; they just mean we won't be able to refresh
  	// the cache. (But, don't ignore them, because that could hide coding errors.)
  	e.waitUntil(
  	networkFetchPromise
  	.then(res => refreshCacheFromNetworkResponse(e.request, res))
  	.catch(err => {
  	console.warn(`Could not refresh the cache for ${e.request.url}`, err);
  	})
  	);
  	return cachedResponse || networkFetchPromise;
  	})
  	);

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