Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order of stylesheet load events and script execution #4020

Closed
emilio opened this issue Sep 10, 2018 · 10 comments
Closed

Order of stylesheet load events and script execution #4020

emilio opened this issue Sep 10, 2018 · 10 comments

Comments

@emilio
Copy link
Contributor

emilio commented Sep 10, 2018

First, I don't know whether there's an issue on file for this or not already.

Consider the following test-case, with a foo.css file that contains:

body { color: green }
<!DOCTYPE html>
<link rel="stylesheet" href="foo.css" onload="console.log('onload')">
<body>
<script>
  console.log("script");
  console.log(getComputedStyle(document.body).color);
</script>

Gecko will wait for the stylesheet to be loaded in order to execute the script, and thus will always log onload, then script, then rgb(0, 128, 0).

I haven't checked Edge, but Blink and WebKit both don't wait for the sheet load. What is the expected behavior here?

Just for reference, I found it because a website was relying on Gecko's behavior: rust-lang/mdBook#784

@emilio
Copy link
Contributor Author

emilio commented Sep 10, 2018

cc @bzbarsky

@annevk
Copy link
Member

annevk commented Sep 10, 2018

cc @domfarolino

@domfarolino
Copy link
Member

What exactly is the behavior you're experiencing with Blink/WebKit? I've spun up script-after-style, which is the code in your comment, however the <link> takes 3 seconds to load intentionally, for exaggerated effect. The console output I see is:

script
rgb(0, 128, 0)
onload

This output appears only after 3 seconds (after the <link> loads), and the rgb is correct. Since the order of logged items differs, this seems to suggest that the <script> is indeed blocked on the stylesheet, but that there may be a task source/event loop quirk here. I too would expect the onload to appear first. Lemme look into it more.

@emilio
Copy link
Contributor Author

emilio commented Sep 10, 2018

Hmm, I guess the load event order confused me a lot, but you're right that it was spec'd. What I saw I guess is a (potentially related) Chrome bug, that you can see in:

https://script-after-style-.glitch.me

(Sorry, shamelessly copy-pasted :)).

I'd also expect the disabled CSSOM setter to take effect.

@domfarolino
Copy link
Member

The effect seems spec'd, however the order might violate something that I'm currently digging around looking for. RE the site you've pasted above, I'm seeing the word "Should not be red", in black text in both latest Chrome (and stable actually), and Firefox. Is there a difference/effect that I'm missing?

@emilio
Copy link
Contributor Author

emilio commented Sep 11, 2018

I see it red in Chrome 68.0.3440.106 (Developer Build) Fedora Project (64-bit). Though you're right it's not red on Chrome 70, so I guess it's been fixed.

@domfarolino
Copy link
Member

Interesting. Regardless, the ordering of outputs seems interesting...perhaps we should rename this issue? I've also written http://script-after-style.glitch.me/test.html, which you can view-source of to see a test that illustrates the ordering being quite observable. Have to see if this is a violation though (haven't had much time today).

@emilio
Copy link
Contributor Author

emilio commented Sep 11, 2018

Yeah, renaming sounds great, though not sure to what... "Order of stylesheet load events and script execution" maybe? Feel free to rename it if needed.

@emilio emilio changed the title Blocking script execution on stylesheet loads. Order of stylesheet load events and script execution Sep 11, 2018
@domfarolino
Copy link
Member

Ah, knew this sounded familiar. The behavior (wrt ordering) is something we've seen at #3610 I think. I'll go ahead and comment over there, and let @annevk decide whether this should be closed or not.

@annevk
Copy link
Member

annevk commented Sep 11, 2018

Happy to dupe this into #3610.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants