Changing <link rel="stylesheet"> media type from non-matching to matching value *sometimes* triggers an additional request |
|||||||
Issue descriptionhttp://filamentgroup.github.io/loadCSS/test/110-reducedexample.html I can't recreate this by refreshing the page, but this seems to recreate the issue reliably: 1. Open a new tab 2. Open devtools network tab so you can see the requests 3. Navigate to http://filamentgroup.github.io/loadCSS/test/110-reducedexample.html 4. Two requests in devtools Video of issue https://www.youtube.com/watch?v=y4ltmB5-Yp8&feature=youtu.be This was spotted by the developers of loadCSS https://github.com/filamentgroup/loadCSS/issues/134#issuecomment-191479025
,
Mar 10 2016
It happens when changing from matching to matching or non-matching to non-matching as well. We do a LinkStyle::process() whenever media changes on link which causes a stylesheet clear + load. That shouldn't be necessary. Notes: 1. A link rel=stylesheet still loads for non-matching media queries, even unknown media types. 2. The media type makes the stylesheet non-blocking if it doesn't match when we start loading. If the expected behavior is that we shouldn't change blocking/non-blocking behavior of the stylesheet when changing media while loading, the fix is just to just set the media query for the media attribute, and if there is an existing stylesheet which has finished loading, do necessary stylesheet ruleset + metadata + style recalc.
,
Mar 12 2016
,
Mar 13 2016
CL for review: https://codereview.chromium.org/1793933002/
,
Apr 7 2016
As the issue requires some cleanup of HTMLLinkElement & LinkLoader, I'll take ownership.
,
Sep 8 2016
,
Mar 29 2017
,
May 8 2017
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by timloh@chromium.org
, Mar 4 2016Status: Available (was: Untriaged)