1403107 - `<link>` tag should load dataurl blocking

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect, P3)

Description

[git]

Attachment: reproduce this bug

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce:

step to reproduce:
1. download attachment(learn.html)
2. open learn.html with firefox browser
3. open web console in firefox
4. refresh this tab in firefox
5. look at console output in firefox


Actual results:

actual results: rgb(0,0,0)


Expected results:

expected results: rgb(255,0,0)

Test with Chrome 61、MS Edge、IE、Firefox in Windows 10 x64 and macOS High Sierra.
Other browser except firefox output: rgb(255,0,0)

Comment 1

[Valentina Claudia Ona]

This issue is reproducible using latest Nightly 58.0a1 on Ubuntu 16.04 and Mac OS X 10.12

Comment 2

[Jet Villegas (inactive)]

The result described is consistent with stylesheets loaded from external CSS files, as in this posted example:
http://media.junglecode.net/test/1403107/learn.html

Note that the test above behaves the same in Firefox, Edge, Chrome and Safari. I think the security restrictions on data URI's is intentional. Xidorn: can you confirm? Thx!

Comment 3

[Xidorn Quan [:xidorn] UTC+10]

There is nothing about security restriction here. This styesheet is correctly loaded and rendered.

This bug is very specific to reading computed value immediately after adding a new stylesheet. The code getting the old computed value is not because we block anything. It is simply because we always start loading stylesheet asynchronously (if it hasn't been loaded for the current page, IIRC), even if it is a data URI. It means that if you try getting computed value synchronously like in this code, the newly-inserted stylesheet hasn't taken effect.

Ironically, I myself actually filed a very similar bug years ago (bug 545636, which is the first bug I filed on bugzilla). In that bug, I was doing the same thing that getting computed value immediately after adding a new stylesheet. I filed that bug because other browsers load local stylesheet synchronously, but Firefox doesn't. It was closed as INVALID by bz, and now I think that's probably a reasonable resolution.

I'm indeed a little concerned about the fact that we have different behavior than other browsers in this case (data URI stylesheet) as well as for local files (which is likely the real issue people file this kind of bugs for). But I'm not sure how much value there is to make our behavior identical to others for the cases.

For data URI case, when you construct the content of the stylesheet, it is always easier and more reliably to use <style> element rather than <link> element with data URI.

For file reference, most of time they should be loaded from the network, where loading is rather unreliable than local files. Given that no browser blocks script execution on stylesheet insertion, if author relies on stylesheet getting loaded synchronously when tested with local files, their page would simply be broken when it is put on the Internet.

To get consistent behavior among browsers, as well as different network environment, you should listen to "load" event of the <link> element instead.

We may want to have data URI stylesheet loaded synchronously, so that people would stop filing bugs with this kind of imaginary testcase (is there a real world usecase that <link> with data URI is better than <style>?), although that probably isn't worth.

Comment 4

[Daniel Holbert [:dholbert]]

[marking wontfix for 57 (current beta) - if we take a patch for this at all, it doesn't sound like there's any particular need for this in 57.]

Comment 5

[Boris Zbarsky [:bzbarsky]]

> I'm indeed a little concerned about the fact that we have different behavior than other browsers in this case

I am too, because that means the other browsers are totally violating the HTML and fetch specs.  Those specs are very clear: HTML says that stylesheets are loaded via fetch, and fetch says that all fetches, including data:, are async.

Anne, please correct me if I missed something here.

> We may want to have data URI stylesheet loaded synchronously

I really don't think we should.  Decoding a data URI and parsing it into a stylesheet can be an expensive operation, and forcing it to happen synchronously on the main thread is horrible.

That said, I just tested some other browsers.  In Safari, the first time I load the testcase I get "rgb(0, 0, 0)".  If I then reload, I start getting "rgb(255, 0, 0)".  So it looks like Safari does the load async but then has some sort of stylesheet object cache that gets applied sync or something.  Oh, and if I load the testcase in a new tab I get "rgb(0, 0, 0)" again.  In practice, what that means is that trying to use code like this in Safari will sometimes work, and sometimes not, kind of randomly.  I really don't think that's a good idea to either specify or implement.

I filed https://bugs.webkit.org/show_bug.cgi?id=177847 on Safari and https://bugs.chromium.org/p/chromium/issues/detail?id=771425 on Chrome.  I can't report bugs on Edge, because they refuse to create a bug-reporting account for any of my email addresses...

Comment 6

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Boris Zbarsky [:bz] (still digging out from vacation mail) from comment #5)
> I filed https://bugs.webkit.org/show_bug.cgi?id=177847 on Safari and
> https://bugs.chromium.org/p/chromium/issues/detail?id=771425 on Chrome.  I
> can't report bugs on Edge, because they refuse to create a bug-reporting
> account for any of my email addresses...

You can try filing Edge bug via using #EdgeBug tag on Twitter with a demo page showing the issue. They will create a bug for you :)

Comment 7

[Boris Zbarsky [:bzbarsky]]

> You can try filing Edge bug via using #EdgeBug tag on Twitter with a demo page showing the issue

Oh, nice.  Done.  ;)