From https://www.w3.org/Bugs/Public/show_bug.cgi?id=24484#c6

> i think that it'd be clearer in the spec to have one notion of "do my stuff
> after script has done doing it's thing". i suggest refactoring the stable
> state stuff to use microtasks instead.

Filing a separate bug so that this gets considered.

Note that there are two places that perform a microtask checkpoint that do
not provide a stable state:

http://www.whatwg.org/specs/web-apps/current-work/#clean-up-after-running-a-callback
http://www.whatwg.org/specs/web-apps/current-work/#spin-the-event-loop

I'm not familiar enough with these concepts to say if it would be a problem to run the sync sections of HTMLMediaElement here.

Pre-emptive reply to "but these concepts are completely different!":

It is true, as the spec notes, that "A synchronous section never mutates the DOM, runs any script, or has any side-effects detectable from another synchronous section, and thus synchronous sections can be run in any order, and cannot spin the event loop."

This is rather different from microtasks, which have none of these properties.

However, does it really matter? If we use microtasks for HTMLMediaElement they can still avoid running scripts and modifying the DOM. They would run in a well-defined order, as opposed to synchronous sections, but so what?

I asked Hixie about these properties and he said the motivation was so that they could be run in parallel.

AFAIK, no browser actually does this and it's hard to see how it would be worth it, given existing uses.

Thinking some more about the consequences of using microtasks in HTMLMediaElement:

The resource selection algorithm can be aborted, in which case one implicitly stops awaiting a stable state. With microtasks, one would have to explicitly remove them from the queue in load(), just like with the event firing tasks.

The step "Wait until the node after pointer is a node other than the end of the list. (This step might wait forever.)" would have to be made into a proper hook for source element insertion.

Breaking the algorithms that await a stable state into several pieces like this would make the spec look more complicated, I suppose, but it would be more similar to how it is actually implemented.

Relevant discussion on IRC:

http://krijnhoetmer.nl/irc-logs/whatwg/20140219#l-367

To continue the monologue, a quickfix which wouldn't require rewriting all the algorithms is to let "perform a microtask checkpoint" provide a stable state after running all the microtasks, and not provide a stable state anywhere else.

The downside would be that synchronous sections and microtasks are never interleaved, so microtasks can't be used to test synchronous sections. On the other hand, since microtasks can modify the DOM, it does make sense to let them finished before calling it a stable state...

I don't want to merge them since they are quite different (one is serialised, the other is parallelisable; one is queued, the other is a joining of threads; they are editorially very different). However, I'm happy to have them defined such that they are implementable in terms of one another, modulo bug 24707. This would get you what you presumably want out of this.

(In reply to Ian 'Hixie' Hickson from comment #8)
> I don't want to merge them since they are quite different (one is
> serialised, the other is parallelisable; one is queued, the other is a
> joining of threads; they are editorially very different). However, I'm happy
> to have them defined such that they are implementable in terms of one
> another, modulo bug 24707. This would get you what you presumably want out
> of this.

Is what I suggested in comment #7 sound, or do you have something else in mind for "implementable in terms of one another"?

I'd probably do it more like queueing a microtask that provides a stable state, or something like that. I haven't check in detail yet. Depends somewhat on how we end up speccing microtasks.

(In reply to Ian 'Hixie' Hickson from comment #10)
> I'd probably do it more like queueing a microtask that provides a stable
> state, or something like that. I haven't check in detail yet. Depends
> somewhat on how we end up speccing microtasks.

I suppose the layering (stable state on top of microtasks) would be slightly cleaner that way. The only question is if all pending synchronous sections get run in a single microtask or if each "await a stable state" queues a separate microtask. I think the latter probably makes more sense, since otherwise the order of the synchronous sections and other microtasks queued by some piece of code would depend on whether or not some other code in the same script has previously run "await a stable state" or not...

I can probably live with any solution here that Rafael finds acceptable.

We provide a stable state without running microtask checkpoints in the pause algorithm. But I hadn't thought to check for the opposite before.

We run microtasks without providing a stable state in these cases:
 - spinning the event loop runs microtasks twice back to back and only then
   provides a stable state (maybe we should drop the first of the microtask runs,
   since running microtasks always runs all pending microtasks anyway, so the
   second is always a no-op, if I'm not missing anything here.)

 - cleanup after calling a callback runs microtasks but doesn't provide a stable
   state. This manifests for example in event dispatch — after each event, we
   run microtasks, but we wait until all the events have been processed before
   providing a stable state. So for example, if you have two click event handlers,
   and one creates a <video> with one src="" and the next changes the src="", the
   spec right now says the first one isn't fetched at all.

I think that's it.

I guess we can fix these without much controversy.

I just stumbled upon a problem with having synchronous sections run in any order. While they don't modify the DOM, they do queue tasks (to fire events). That is observable. Without realizing it, I've been writing tests that depend on the order of synchronous sections to match the order in which "await a stable state" happens.

A simplified test might be:

var v0 = document.createElement('video');
var v1 = document.createElement('video');
var order = [];
v0.onloadstart = v1.onloadstart = function(e) {
  order.push(e.target);
  if (order.length == 2) {
    assert_equals(order[0], v0);
    assert_equals(order[1], v1);
  }
}
v0.src = '';
v1.src = '';

In other words, whatever ends up spec'd here, the order in which synchronous sections run should be deterministic.

Each media element has a different task source, so those two events aren't guaranteed to be ordered anyway.

(In reply to Ian 'Hixie' Hickson from comment #14)
> Each media element has a different task source, so those two events aren't
> guaranteed to be ordered anyway.

Oh right, I keep forgetting about that since they weren't actually separate queues in Presto. (They kind of are in Blink/WebKit, although the order is still guaranteed in the simple example I gave.)

Any chance of progress on this? Other people are wanting to "await a stable state" in Blink as well now: https://codereview.chromium.org/200923002/

Is the "I want alert to not block a video loading" the only thing currently blocking merging stable state and microtasks.

If so, I plan to just push blink to just merge them.

What does "just merge them" mean? It certainly looks like the spec is going to define "await a stable state" in terms of microtasks, and there are subtleties there which need testing. Before the spec materializes I don't know what test cases one should write.

The answer to the (In reply to contributor from comment #0)
> Comment:
> Can the microtask and stable state concepts be merged?
No

Stable state happens between tasks.

There can be several microtasks within one task, and several
"end-up-microtask" points. For example end of each
top level event listener call.
It would be odd to start running stable state stuff after each
(top level) callback - or at least such change would be rather radical.

As far as I can tell, the question is: "can the uses of stable state just post a microtask to do their work instead?"

The only reason I've heard why this won't work is Hixie's "I want to load a video, open an alert, and I want the video to load while the alert is open", which seems like a pretty trivial use in order to maintain an entirely separate notion in the spec.

I vote that the work done as a result of the browser "providing a stable state" simply post microtasks to do their work instead.

Any chance we can get this bug resolved soon? This is currently blocking implementation of the <picture> element in Blink. I'd like to get this implemented for image loading sooner than later, and ideally with the simpler version of just having a microtask.

I assume will need to have stable state concept in workers too, and there
alert() case is very valid. Using sync XHR for example is totally ok,
and the more we expose stuff there, the more it will look like main thread.

It seems like it should be possible to run microtasks on a worker thread even while the main thread is blocked on an alert?

I mean, not sure if the spec is allowing that right now, but that shouldn't be a conceptual problem...

I'm talking about worker case only. Synchronous stuff there and resource loading etc.

So the issues here are:

 - all synchronous sections (stable state consumers) run in parallel
 - we don't want to run synchronous sections until after all events have been 
   dispatched, when doing even dispatch, but we do want mutation observers to
   run after each one
 - the alert thing, though people seem to be ok with having video loads stall
   if the script shows an alert after setting the src (bug 24707)

We could do something for stable states similar to what we do for mutation observers:

 - whenever you currently wait for a stable state, you also make sure there's a 
   microtask queued for handling that stable state.
 - whenever you run that microtask, you provide a stable state.

...but that would still leave the problem with event dispatch...

Should we just not bother trying to maintain that invariant? It'll result in redundant Web traffic and stuff, but I guess it's understandable to authors...

(In reply to comment #25)
> So the issues here are:
> 
>  - all synchronous sections (stable state consumers) run in parallel

My memory is that we discussed this and no one actually cares about this. IOW, you spec'd it this way thinking it'd be a perf win, but no one implements it that way nor plans to.

>  - we don't want to run synchronous sections until after all events have
> been 
>    dispatched, when doing even dispatch, but we do want mutation observers to
>    run after each one

Why is that?

>  - the alert thing, though people seem to be ok with having video loads stall
>    if the script shows an alert after setting the src (bug 24707)
> 
> We could do something for stable states similar to what we do for mutation
> observers:
> 
>  - whenever you currently wait for a stable state, you also make sure
> there's a 
>    microtask queued for handling that stable state.
>  - whenever you run that microtask, you provide a stable state.
> 
> ...but that would still leave the problem with event dispatch...
> 
> Should we just not bother trying to maintain that invariant? It'll result in
> redundant Web traffic and stuff, but I guess it's understandable to
> authors...

What's the benefit of losing the parallelisability? If there's a win from losing it, then ok, but it seems silly to explicitly require that it not be possible, especially if there's not really any black-box way to tell.

Comment 12 has an example of the multi-handler thing:
> for example, if you have two click event handlers, and one creates a <video>
> with one src="" and the next changes the src="", the spec right now says the
> first one isn't fetched at all.

(In reply to Ian 'Hixie' Hickson from comment #27)
> What's the benefit of losing the parallelisability? If there's a win from
> losing it, then ok, but it seems silly to explicitly require that it not be
> possible, especially if there's not really any black-box way to tell.

Unless I misunderstand, you put this in here based on the idea that someone may do it someday. It seems to me that any addition to the spec must either be reflected in someone's actual implementation, or it's up to the person who adds it to justify its value.

The value of loosing it is decreased complexity in the spec (and blink which likes to have implementation abstractions closely match the spec language) -- and making progress towards only have a single "let script finish doing it's thing" mechanism (i.e. microtasks).



> 
> Comment 12 has an example of the multi-handler thing:
> > for example, if you have two click event handlers, and one creates a <video>
> > with one src="" and the next changes the src="", the spec right now says the
> > first one isn't fetched at all.

I guess it's not like these things are going to happen at the exact same time that often. Fine. I'll just make them use regular microtasks somehow.

OK great. Can I assume for now that https://www.w3.org/Bugs/Public/show_bug.cgi?id=24707 will be resolved in such a way that alert() will not provide a stable state anymore?

Sadly, yes, that's probably a good assumption.

(though I intend to keep an eye on implementations here and if I see a sign that they're not doing it that way, I will change it back.)

(In reply to Ian 'Hixie' Hickson from comment #29)
> I guess it's not like these things are going to happen at the exact same
> time that often. Fine. I'll just make them use regular microtasks somehow.

Assuming you intend to reword the media element algorithms to use microtasks, I'd be happy to review those changes. Both Presto and Blink/WebKit already have to split those algorithms into pieces, so this should make the spec more similar to the implementations.

This ended up being somewhat trivial to spec. Let me know if that's because I missed something important!

Checked in as WHATWG revision r8630.
Check-in comment: Refactor 'stable states' to be defined in terms of microtasks
http://html5.org/tools/web-apps-tracker?from=8629&to=8630