data: stylesheets incorrectly loaded synchronously
Reported by
bzbar...@mit.edu,
Oct 4 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:58.0) Gecko/20100101 Firefox/58.0 Steps to reproduce the problem: 1. Load attached testcase What is the expected behavior? Text should be green. What went wrong? Text is red. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 63.0.3230.0 (Official Build) dev (64-bit) Channel: n/a OS Version: OS X 10.12 Flash Version: Shockwave Flash 26.0 r0 The HTML spec uses fetch to get the resources referenced by <link> elements (see <https://html.spec.whatwg.org/multipage/semantics.html#obtaining-a-resource-from-a-link-element>) and fetch is always an async operation. So the computed style is gotten before the new stylesheet has loaded, and hence the color should be green. Note related https://bugs.webkit.org/show_bug.cgi?id=177847 for Safari (which sometimes behaves sync here, sometimes async). Firefox always behaves async here. In general, data: URI decoding and CSS parsing can be expensive operations, and requiring them to be sync doesn't make sense. So I'm not sure why Blink is doing the whole thing synchronously.
,
Oct 4 2017
Able to reproduce this issue on reported version 63.0.3230.0 and on latest canary 63.0.3232.0 using Mac 10.12.6,Windows 10 and Ubuntu 14.04. i.e; Text is seen in red colour. This issue is seen from the M50(50.0.2661.0). Hence considering this as Non-regression and marking it as Untriaged. Thanks!
,
Oct 4 2017
,
Oct 23 2017
,
Nov 9 2017
This issue can be split into two sub-issues: Sub-issue 1. data: stylesheet's loading should finish asynchronously. (i.e. the stylesheet should not be applied just after <link> is inserted, even when it is data: URL) 2. URI decoding should be done asynchronously. For sub-issue 1: Loading data: URLs has been done perhaps for performance, and Issue 237366 is trying to make all types of loading async including CSSs. As mentioned in the Safari issue, this sync code path is also used for stylesheets on MemoryCache. If Issue 237366 is fixed (not sure this can be done in a short-term), then sub-issue 1 will be fixed, i.e. the stylesheet parsing is done asynchronously, and the style is applied asynchronously. Sub- issue 2 will remain even after Issue 237366 is fixed, because currently data URI parsing is done when a request to the data URI is initiated (Issue 237366 will only make notification of load finish async, and data URI parsing will remain synchronous). Do you have motivating examples/use cases for sub- issue 2 , i.e. cases where data URI parsing (not CSS parsing) causes performance problems?
,
Nov 9 2017
You can have a large base64-encoded data: URI (think hundreds of megabytes). The CSS parsing will be slow in that case too, of course, but so will the base64 decoding.
,
Mar 4 2018
So it seems that Issue 237366 is the only blocker for this issue, and even with sub- issue 2 existing, the styles will still be applied correctly, since they are loaded async right? And the motivation for solving sub- issue 2 is purely for performance, not webcompat or correctness? I should add that with some guidance, I would like to tackle sub- issue 2 and dig into perhaps making that parsing async and thus more performant - would you be interested in helping me alone hiroshige@ ? |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by nyerramilli@chromium.org
, Oct 4 2017