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

Mon Aug 9 09:35:47 PDT 2010

On 8/9/10 12:14 PM, Philip Jägenstedt wrote:
>> Why? Maybe if I understood what we're trying to accomplish with the
>> synchronous section bit here I'd have a better idea of how it should
>> work...
>
> The general idea of waiting is that since the following steps of the
> resource selection algorithm inspects video elements src attribute and
> source element children, those should be in a consistent state before
> the checking is done.

OK, but then why are we not imposing such a requirement for the case 
when the <video> is being created by the parser?

> <body>
> <script>
> var v = document.createElement('video');
> var exts=["webm", "mp4"];
> exts.forEach(function(ext) {
> var s = document.createElement('source');
> v.appendChild(s);
> s.src = "foo."+ext;
> s.type = "video/"+ext;
> document.body.appendChild(v);
> });
> </script>
>
> Unless we wait until the script has finished before running the
> synchronous section, no source at all will be selected

Because changes to the set of <source> elements do not restart the 
resource selection algorithm, right?  Why don't they, exactly?  That 
seems broken to me, from the POV of how the rest of the DOM generally 
works (except as required by backward compatibility considerations)...

> However, as long as the same is true in all browsers this seems
> easy to fix in the script itself, just a bit non-obvious.

But why are we purposefully introducing hysteresis into the DOM?  It'd 
make a lot more sense to me to not have hysteresis here if at all possible.

> I'm trying to come up with a big scary problem that would motivate the
> complexity of "await a stable state", but I can't see it. I doubt
> StackOverflow would be flooded by issues caused by quirks as the one
> above.

It actually probably would, if if we actually had such a quirk.

> 1. Remove the "await a stable state" concept and just continue running
> the steps that follow it. (This is what Opera does now when resource
> selection is triggered by the parser, as I have no idea how long to wait
> otherwise.)

I have a really hard time believing that you trigger resource selection 
when the <video> is inserted into the document and don't retrigger it 
afterward, given that... do you?

> 2. Instead of calling the resource fetch algorithm in step 5/9

There doesn't seem to be such a step...

> 3. In step 21, instead of waiting forever, just return and let inserting
> a source element cause it to continue at step 22.

Again, the numbering seems to be off.

> Since this doesn't introduce any new concepts to the spec, I assume it
> would be implementable in Gecko?

Given the premise, presumably. But the resulting behavior still seems 
broken in the parser case; see above....

-Boris