Definition of stable state in terms of microtasks does not seem to match browsers

[bzbarsky]

Ever since 65ca3ae "stable state" has been defined in terms of microtasks. This doesn't seem to be what browsers do, though. A testcase is the html/semantics/embedded-content/media-elements/track/track-element/track-delete-during-setup.html web platform test, which in simplified form looks like this:

<video>
  <track src="resources/metadata.vtt">
</video>
<script>
  var track = document.querySelector("track");
  alert(track.readyState);
</script>

When a browser is parsing this file and the <track> is inserted in the DOM, we hit the

The track element's parent element changes and the new parent is a media element.

condition in https://html.spec.whatwg.org/multipage/media.html#sourcing-out-of-band-text-tracks and go into https://html.spec.whatwg.org/multipage/media.html#start-the-track-processing-model. This goes parallel in step 4, and the parallel steps start with "await a stable state", which means a microtask gets queued. I assume the intent here is to queue the microtask before the "allowing whatever caused these steps to run to continue" bit from step 4 happens; otherwise the queueing of the microtask seems like a data race.

If that assumption is correct, then the microtask for the synchronous section is queued before hte browser unwinds from the <track> insertion. If the assumption is not correct, I don't understand how one can make any claims about any of this stuff and its ordering.

Anyway, we move on and the browser parses the <script>. When it sees </script> it lands in https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-incdata and for the </script> case the first step is to perform a microtask checkpoint. This will run the synchronous section for the track bits, and step 6 of that will set the track to the loading readiness state. Then the script runs, and 1 is alerted.

That's not what browsers do. Every single browser passes the wpt, and the wpt is asserting that the readyState is 0, not 1. In other words, the wpt is testing that the script runs before the synchronous section of the track processing model, and every browser implementation does just that. When I tried to update Firefox to treat "await a stable state" as "queue a microtask", this test failed, as did a number of other media tests (content-security-policy/media-src/media-src-7_1_2.sub.html , content-security-policy/media-src/media-src-7_2_2.sub.html , content-security-policy/media-src/media-src-blocked.sub.html). I also got unexpected passes on a bunch of tests under html/semantics/embedded-content/media-elements/loading-the-media-resource and spot-checking them it looks like all browsers fail them right now....

I guess the main question here is whether making this change is web-compatible at all...

@annevk @domenic @jyavenard @jan-ivar

[bzbarsky]

@smaug---- too, since he's looked into this before on the Gecko side....

[smaug----]

Gecko's stable state handling is based on the pre-stable-state-during-microtask model which HTML spec used to have, which used to be basically end-of-task model.

[bzbarsky]

Oh, and I got here from our implementation of https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-decode because that algorithm queues a microtask explicitly, and the tests assume that happens after picture source processing, which happens in stable state.

The only reason Firefox's not-yet-landed implementation passes those tests is that it's using "await a stable state" in decode() instead of queueing a microtask. I just looked, and Blink does use a microtask for decode but also does a microtask, not a stable state (which is what the spec calls for), for image loading, which is the only reason the decode tests pass in Blink.

[bzbarsky]

Gecko's stable state handling is based on the pre-stable-state-during-microtask model

Yes. My point is, so is everyone else's as far as I can tell. So why do we think it's web-compatible to change that model?

[smaug----]

Change was done in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24724

[rniwa]

@jernoble @hobor

[bzbarsky]

I guess one question given the above bit about image loading in Blink is what various browsers use stable state in the old sense for. Is media loading the only thing that consistently does it?

[jan-ivar]

From digging, the "Top: Await a stable state." language was added in 41f8589, predating the microtask/stable state merge.

At that point the definition used to be: "When the user agent is to provide a stable state, if any asynchronously-running algorithms are awaiting a stable state, then the user agent must run their synchronous section and then resume running their asynchronous algorithm (if appropriate)."

If we're looking for original intent. I have no strong opinion on the matter.

[jan-ivar]

Maybe we need both a historical "stable state" and a "microtask stable state"?