This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28920 - If the stack of script settings objects is empty, perform a microtask checkpoint right before executing async or defer script
Summary: If the stack of script settings objects is empty, perform a microtask checkpo...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-06 21:34 UTC by Zibi Braniecki
Modified: 2017-07-21 09:35 UTC (History)
6 users (show)

See Also:

Attachments

Description Zibi Braniecki 2015-07-06 21:34:37 UTC 
While regular <script>'s are executed in a separate task which guarantees that MutationObserver callbacks are executed before them, current spec does not specify any special case for async or deferred scripts.

When working on proof of concept shims for future WebAPI's, it is useful to be able to inject synchronous script that sets MutationObserver whose callback alters Elements injected into DOM.

Without this change, there's no transparent way to inject such shims, since scripts have to additionally be wrapped in DOMContentLoaded callback because only that guarantees that the MO callbacks are executed.

Currently in Safari and Chrome MutationObserver callbacks are called before executing defer scritps, while in Gecko the behavior is not deterministic.
Comment 1 Anne 2015-09-22 15:03:39 UTC 
<script async> is executed from a networking task per https://html.spec.whatwg.org/#set-of-scripts-that-will-execute-as-soon-as-possible.

<script defer> is run from the task that is queued from spinning the event loop, as far as can tell.

So I'm not sure what the problem is here.
Comment 2 Olli Pettay 2015-09-22 18:23:49 UTC 
Where is the task for defer queued?

The related gecko bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1180927
which is only about defer, don't recall if async has any issues.


"Once the user agent stops parsing the document, the user agent must run the following steps:
1.0 ...
2.0 Pop all the nodes off the stack of open elements. 
3.0 If the list of scripts that will execute when the document has finished parsing is not empty, run these substeps:
  3.1. Spin the event loop until the first script in the list of scripts that will execute when the document has finished parsing has its "ready to be parser-executed" flag set and the parser's Document has no style sheet that is blocking scripts. (so we may or may not spin event loop)
  3.2. Execute the first script in the list of scripts that will execute when the document has finished parsing. (So microtask end point doesn't happen between defer scripts)
  3.3. ...
  3.4. ... (loop [3.0])


Without async/defer, we do explicitly "If the stack of script settings objects is empty, perform a microtask checkpoint.", but defer scripts are executed later.
Comment 3 Anne 2015-09-23 06:39:52 UTC 
The first clause of step 15 of https://html.spec.whatwg.org/#prepare-a-script is about <script defer>. That introduces the term "list of scripts that will execute when the document has finished parsing". That term is referenced from https://html.spec.whatwg.org/#stop-parsing as you concluded as well.

Step 3.1 there invokes "spin the event loop". Step 9 of https://html.spec.whatwg.org/#spin-the-event-loop queues a task. That task is used to to run step 3.2 of the algorithm that invoked "spin the event loop", which ends up executing the script.

Now, per the event loop processing model, perform a microtask checkpoint is run in step 7, after running a task. So I think that all adds up.
Comment 4 Olli Pettay 2015-09-23 09:51:02 UTC 
3.1 spins event loop _only_ if "ready to be parser-executed" isn't set, or that is at least the way I interpret it.
Comment 5 Olli Pettay 2015-09-23 09:52:35 UTC 
(In reply to Olli Pettay from comment #4)
> 3.1 spins event loop _only_ if "ready to be parser-executed" isn't set, or
> that is at least the way I interpret it.

In fact, as far as I see, that is the only way to interpret it, since there might not be anything in the event loop waiting to be processed, if deferred scripts have been loaded already.
Comment 6 Anne 2015-09-23 09:56:33 UTC 
I don't think so, "spin the event loop" takes a goal as argument. So even if the goal is already met, you'd still have to run the steps.
Comment 7 Anne 2017-07-21 09:35:23 UTC 
If this is still unclear for some reason, I suggest raising this again at https://github.com/whatwg/html/issues/new. Thanks!