The inlined CSS in the worker HTML starts with:
For some bizarre reason this causes Chrome (84.0.4147.125 on MacOS 10.13.6) to request the following URL:
The invalid request is immediately followed by a correct request to the proper stylesheet URL, also initiated by the worker frame.
For comparison, in the parent frame’s main stylesheet the font stylesheet is imported via:
- All tests were made without any active extensions.
- I couldn’t observe the behavior in Firefox.
To get rid of the error, it might suffice to remove the wrapping Edit: Wrong conclusion. When the CSS is inlined and the (quoted) import URL contains a raw semicolon, then Chrome will treat this as the end of the statement and treat the URL up to the semicolon (including the
url(" prefix) as relative URL.
Chrome chokes on the semicolon, and URI-encoding each stops the error:
Edit: If others can confirm the problem, then this might qualify as a (very minor) webcompat bug.
So! As you’ve researched, this is a known issue that I’ve been consciously ignoring since it still ends up requesting the correct resource directly after. It:
- is in Chrome only (not in Safari nor Firefox)
- due to the @import …; in a
<style> tag on the page (doesn’t happen without the semicolon and doesn’t happen from a css file either
<link>ed or @import’ed)
See a small reproduction of mine on Codepen.
I’ve been hoping Chrome would fix this, but I was also considering un-inlining the worker css back to its own file, which would also fix this.
This was a change I introduced recently in moving our Source Serif Pro self-hosting to Google fonts. The immediate benefits of the Google-hosted version are smaller font files for most cases (they break up the font’s unicode ranges across files) and the thumbnailer’s kerning used to be pretty awkward, but is now correct.
Update: @mbostock has since suggested an easy fix (moving from @import to a
<link> tag), which should be deployed.