The spec says to provide a stable state for </script> unconditionally. This seems strange, because then document.write('<script></script'+'>'); would provide a stable state, allow sync sections to run while scripts are still running, which seems completely counter to the idea of stable sections.

My understanding is that when an algorithm awaits a stable state, the step following in its sync section should run no sooner that when all current scripts (not just current nesting level) have finished running and no later than before the next time scripts are run. This isn't how the spec states it, but it was how I implemented it in Presto, so I'm arrogantly assuming that any deviation is a spec bug and not a Presto bug.

Experiment: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2772

*** Bug 24356 has been marked as a duplicate of this bug. ***

"Perform a microtask checkpoint." unconditionally at </script> might also be problematic (I'm not familiar with microtasks), but maybe that should be in a separate bug?

I dunno about microtask checkpoints, but I don't understand why there's a problem providing a stable state here, or indeed anywhere, really, so long as the times where this happens are well-defined. What's the risk you're trying to avoid?

It seems to me that the point of stable states for <video> is that the order in which scripts add/remove elements and attributes doesn't matter, since they are allowed to finish first. Providing a stable state while a script is running is counter to that, so I assumed it was not intentional.

I'm not very worried about actual bugs being caused by this, TBH. Simon, do you think it's fine to leave the spec as is? It'll require some pretty interesting test cases mixing resource selection and document.write, but I guess being able to trigger a stable state at known points in a script could also help testing?

Yeah I'm OK with leaving it as is. Being able to provide a stable state in a script would indeed help with writing tests, although document.write('<script><\/script>'); looks like quite the hack...

OK, let's call the INVALID.

In https://codereview.chromium.org/130983011/ it was pointed out that if we provide a microtask checkpoint for document.write('<script><\/script>') then we also need to test document.write() and document.close() in that mutation callback. 

It's not required for Web compat to provide a microtask checkpoint here, or at least Blink previously didn't. Since it isn't useful and creates new cases that people need to spend time on thinking about and testing, I would suggest this spec change:

"If the parser's script nesting level is zero { Perform a microtask checkpoint; Provide a stable state }"

Pretty please?

There's no way that running a microtask checkpoint synchronously upon document.write('<script></script>') is right.

A central invariant of microtasks is that they execute on a fresh script stack (with zero script stack frames below them). Running the checkpoint at document.write violates that.

For posterity:

A central invariant of the microtask timing has to do with isolation. Work types such as Mutation Observers are examples of *decoupled concerns*. The isolation invariant of the microtask timing guarentees that when a microtask work item is run, it is run on a fresh script stack.

The reason for this has to do with allowing all types of decoupled work to complete before inviting others to begin.

By way of counter-example, to run microtask work as a result of document.write or document.appendChild, risks allowing work types arising from microtask items running while the script which invoked write/appendChild was mid-way through completion some work, creating risk on both sides:

The invoking script risks having it's run-time assumptions invalidated by decoupled concerns which essentially pre-empt it

The invoked scripts risk acting on a state of the world (in most cases, the DOM), that is inconsistent.

(I renamed the bug title to reflect what I'm actually asking for now.)

Why is a nested invocation of the parser parsing the </script> end tag any different than dispatchEvennt() or any of the other cases where we pop the script settings object stack? There's lots of ways to have a microtask checkpoint when script is running. You just need to cause a reentrant callback to be run, and when the stack is popped, it'll run the checkpoint.

(In reply to Ian 'Hixie' Hickson from comment #12)
> Why is a nested invocation of the parser parsing the </script> end tag any
> different than dispatchEvennt() or any of the other cases where we pop the
> script settings object stack? There's lots of ways to have a microtask
> checkpoint when script is running. You just need to cause a reentrant
> callback to be run, and when the stack is popped, it'll run the checkpoint.

Doesn't "If the stack of script settings objects is now empty" in "clean up after running a callback" mean that no scripts are running?

In any event, that leaves the case in "spin the event loop"... Rafael, what's the plan for that?

Oh, right, I forgot that we put in something to not do them on dispatchEvent(). That still seems silly to me.

I guess we can put in the same restriction on the parser stuff. It seems really weird to me that we care whether it's reentrant or not, though. But I don't think it matters all that much one way or the other, so if y'all think it's more important to do it that way, then ok.

(In reply to Ian 'Hixie' Hickson from comment #14)
> Oh, right, I forgot that we put in something to not do them on
> dispatchEvent(). That still seems silly to me.
> 
> I guess we can put in the same restriction on the parser stuff. It seems
> really weird to me that we care whether it's reentrant or not, though. But I
> don't think it matters all that much one way or the other, so if y'all think
> it's more important to do it that way, then ok.

Since you didn't originally intend for the synchronous sections or microtasks to have a "no scripts are running" restriction, I can understand why it seems silly. AFAICT the restriction isn't strictly needed (the behavior is deterministic without it), but having it has a few benefits:

 * It's closer to existing implementations: I implemented "await a stable state" with that restriction in Presto (admittedly because I failed to understand the spec) and Rafael implemented microtasks with that restriction in Blink.
 * "No scripts are running" is simple to understand, relatively speaking.
 * document.write('<script><\/script>') and document.head.appendChild(script) will be more similar.

>  * document.write('<script><\/script>') and
> document.head.appendChild(script) will be more similar.

Sure, but it also means that creating a document just with document.write() will be less like getting a document from the network, so it cuts both ways.

Anyway, done.

Checked in as WHATWG revision r8479.
Check-in comment: Don't provide a stable state when parsing reentrantly, for more consistency with when we run microtask checkpoints
http://html5.org/tools/web-apps-tracker?from=8478&to=8479

Did you accidentally edit the wrong part of the spec? You added the restriction to the event loop when no tasks (and thus no scripts) are running, instead of the 'An end tag whose tag name is "script"' step I thought we were talking about.

(It's possible that the model of the spec doesn't match the model in Blink, and that I'm confused because of it.)

In any event, I presume this would change again if stable states are expressed in terms of microtasks...

Yikes, yeah, that was the wrong part of the spec! I must have been jumping back and forth comparing them and then was on the wrong one when I made the edit...

Thanks for catching this.

Checked in as WHATWG revision r8498.
Check-in comment: Oops, edited the wrong line. (stable state and </script> parsing)
http://html5.org/tools/web-apps-tracker?from=8497&to=8498

OK, that's much better :) Now reopening again because I expect that Rafael will want the same treatment for microtask checkpoints. (I changed the title of the bug mid-discussion.)

Uh, yeah, not sure why but I had it in my head that we were already checking this for microtasks. I guess we only actually check it in "clean up after running a callback". Ok, done. This was my intend when doing the previous checkin.

Checked in as WHATWG revision r8507.
Check-in comment: Prevent microtasks from running reentrantly via the parser.
http://html5.org/tools/web-apps-tracker?from=8506&to=8507

Looks good, I'll proceed to write tests for this case!