[whatwg] <video> "await a stable state" in resource selection (Was: Race condition in media load algorithm)

Wed Aug 11 12:14:20 PDT 2010

On 8/11/10 5:13 AM, Philip Jägenstedt wrote:
> Yes, in the case of the parser inserting source elements that fail one
> of the tests (no src, wrong type, wrong media) the algorithm will end up
> at step 6.21 waiting. It doesn't matter if all sources are available
> when the algorithm is first invoked or if they "trickle in", be that
> from the parser or from scripts.

Right, ok.  Thanks for bearing with me on this!

> It's quite serious because NETWORK_EMPTY is used as a condition in many
> places of the spec, so this absolutely must be consistent between browsers.

OK, gotcha.

> Otherwise the pointer could potentially reach the same source element
> twice, with the aforementioned problems with failing after network access.

But this would only happen in a rare case, right?  Specifically, that of 
source elements being inserted out of order...  And if the update to new 
source elements being inserted were fully async, it would only happen if 
you trickle the source elements in out of order.

But yes, your idea of flagging a source when it fails would also address 
this just fine.

> OK, perhaps I should take this more seriously. Making the whole
> algorithm synchronous probably isn't a brilliant idea unless we can also
> do away with all of the state it keeps (i.e. hysteresis).

State is not necessarily a problem if it's invalidated as needed....

> One way would be to introduce a magic flag on all source elements to
> indicate that they have already failed. This would be cleared whenever
> src, type or media is modified.

This seems eminently doable.

> Yes, it sounds like it very much does, and would result in disasters
> like this:
>
> <!doctype html>
> <video src="video.webm"></video>
> <!-- network packet boundary or lag? -->
> <script>alert(document.querySelector('video').networkState)</script>
>
> The result will be 0 (NETWORK_EMPTY) or 2 (NETWORK_LOADING) depending on
> whether or not the parser happened to return to the event loop before
> the script. The only way this would not be the case is if the event loop
> is spun before executing scripts, but I haven't found anything to that
> effect in the spec.

I don't think there is anything, no...

-Boris