whatwg.org ServiceWorker experiencing CORS errors on preloaded crossorigin resources
Categories
(Core :: DOM: Networking, defect, P3)
Tracking
()
People
(Reporter: asuth, Unassigned)
References
()
Details
(Whiteboard: [necko-triaged])
:annevk brought https://github.com/whatwg/whatwg.org/issues/253 to my attention but I'm not able to look into it right now. Filing this bug for further tracking, and because this likely exists in the nexus between the Necko team and the DOM: Workers & Storage team.
|
||
Updated•6 years ago
|
|
||
Updated•5 years ago
|
|
|
||
Comment 1•5 years ago
|
||
I think there's a cache problem. E.g., we do a non-CORS favicon request. And then we do a CORS logo request for the same URL. The second ends up with a mismatch somehow.
|
|
||
Comment 2•5 years ago
|
||
I can now reliably reproduce comment 1.
So <link rel=icon> and <img> for the logo both point to the same resource.
- Visit about:serviceworkers and clear the whatwg.org service worker.
- Visit whatwg.org and observe the logo in full glory to the left of "Welcome to the WHATWG community". Also observe that the developer console is empty.
- Wait a bit and then refresh once or twice.
- The logo is now an empty square and the developer console contains "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://resources.whatwg.org/logo.svg. (Reason: CORS request did not succeed)."
Now <link rel=icon> does have a crossorigin attribute. Not taking that into account is problematic and might be a reason for this failing, but the service worker is also caching the logo using the cache API so something else might be going amiss too.
|
||
Comment 3•4 years ago
|
||
This seems to be fixed now that 1661075 is resolved.
|
|
||
Comment 4•4 years ago
|
||
I can confirm this is no longer an issue using 83.0a1 (2020-10-16). Thanks so much Andreu!
Description
•