Consider changing task source for link "error"/"load" events

[domfarolino]

Right now the spec the spec mentions at the bottom of 4.2.4.3 Obtaining a resource from a link element that the task source for the "error"/"load" events is the DOM manipulation task source. Given the aforementioned events are primarily network-based, it might make sense to queue these from the networking task source instead.

Aside:

I created this gist to see if I could observe the "load" event of a link element that is blocking the pending parsing-blocking script of a Document, before the script's execution, and even further before the DOMContentLoaded event is observed. Given the gist, Chrome gives the following in the console:

async script start
async script end
Pending parsing-blocking script now executing
DOMContentLoaded
<link> load event fired

while Firefox yields:

async script start
async script end
<link> load event fired
Pending parsing-blocking script now executing
DOMContentLoaded

The latter makes more sense to me, since for the inline script to run, the link event has to be loaded, of course. The spec is written this way, and Chrome is currently non-compliant (there are actually two issues with Chrome, DOMContentLoaded is fired synchronously and the networking task source is actually used for the link element).

However, Anne makes a good point in that networking-driven events should come from the networking task source, which can of course be prioritized in an implementation-dependent manner relevant to the DOM manipulation task source. This example is a specific instance where it would be convenient otherwise, but his point overall makes sense.

[annevk]

This also came up in #3544 with @domenic.

[domenic]

It looks like I'm on track to fix it as part of that.

[domenic]

I am no longer on track to fix it as part of that, as #3544 descended into "oh gawd everything is broken we need to start over and write a ton of tests". So, a more targeted fix for just the task source issue would make more sense.

[domfarolino]

The issue regarding the ordering of <link> onload/onerror events being fired in relation to the pending parsing-blocking script being executed came up once more in #4020. This seems to be a Chrome bug, but I want to be sure, so I have a question: It's clear that pending parsing-blocking scripts cannot execute until style sheets that are marked as script-blocking are no longer categorized as script-blocking. This is clear from the usage of "spin the event loop" in the scriptEndTag parser algorithm. With this, I'm wondering after the event loop has spun to the point such that there are finally no more script-blocking style sheets, does this guarantee:

• The style sheet is known to be obtained/failed, and the appropriate "load"/"error" event has been dispatched
• ...or only that the resource is known to be obtained/failed (there is some resolve, though the corresponding event is not guaranteed to be dispatched yet)

If it's the former, the spec is fine and Chrome has a bug. If it's the latter, I think it would be nice to try and change the spec to make it the former, so we can guarantee, at least in this circumstance, well-ordered event dispatching.

/cc @domenic @emilio

---

Edit

Anne has answered this over IRC. The plan moving forward wrt the weird ordering is probably to:

• Have style sheet link to css style sheet (is this viable?)
• Rename the style sheet ready flag to something like "style sheet done"
• Actually set the "style sheet done" flag probably as a part of the task that is queued once a resource has finally been obtained so that we can more explicitly remove a resolved resource from the set of style sheets that block scripts.
• Write tests!

[bzbarsky]

@domfarolino's plan sounds good to me, fwiw.