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

Tue Aug 10 01:40:39 PDT 2010

On Mon, 09 Aug 2010 18:35:47 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> 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?

Because the parser can't create a state which the algorithm doesn't  
handle. It always first inserts the video element, then the source  
elements in the order they should be evaluated. The algorithm is written  
in such a way that the overall result is the same regardless of whether it  
is invoked/continued on each inserted source element or after the video  
element is closed. However, scripts can see the state at any point, which  
is why it needs to be the same in all browsers.

>> <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)...

The resource selection is only started once, typically when the src  
attribute is set (by parser or script) or when the first source element is  
inserted. If it ends up in step 21 waiting, inserting another source  
element may cause it to continue at step 22.

Restarting the algorithm on any modification of source elements would mean  
retrying sources that have previously failed due to network errors or  
incorrect MIME type again and again, wasting network resources. Instead,  
the algorithm just keeps it state and waits for more source elements to  
try.

>> 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 not sure what you mean by hysteresis, but guess you mean the somewhat  
ridiculous amount of state one has to keep track of? I think the root  
cause of this is that if a source fails due to network errors (i.e.  
asynchronously after the resource selection algorithm has returned) then  
we want to try the next one. If we threw this out the window, then one  
could define the algorithm in such a way that it only needs to be run  
synchronously once and then be done. I could live with such a solution,  
but I don't think it's the best one.

>> 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.

OK, let's not debate this point :)

>> 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.

These are steps in the resource selection algorithm, not in the resource  
fetch algorithm.

>> 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....

No, in the parser case I am very confident that it will work just fine, as  
this is almost exactly what we already do. It's only in the case of  
scripts that there's a risk of introducing new quirks. However, at this  
point it's likely that some scripts are already doing things in the  
"wrong" order, so perhaps it's too late to make the change I am suggesting.

Mozilla is implementing this now. How are you interpreting "await a stable  
state" when the resource selection algorithm is triggered by the parser?  
Will the result be 100% predictable or depend on "random" things like how  
much data the parser already has available from the network?

-- 
Philip Jägenstedt
Core Developer
Opera Software