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

Mon Aug 9 09:14:44 PDT 2010

This goes quite a bit from the original topic, so renaming accordingly.  
The issue at hand is the "await a stable state" concept in the resource  
selection algorithm:  
<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm>

On Mon, 09 Aug 2010 14:16:04 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/9/10 6:28 AM, Philip Jägenstedt wrote:
>> Let's focus on how this interacts with the parser, because that probably
>> changes everything else to fall into place, see below.
>
> OK.
>
>> In the case of a script triggering it, it's important that the
>> synchronous section not be run until the script has finished modifying
>> the DOM.
>
> 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. In particular, if a script is removing and inserting  
source elements, then after any given modification the DOM might not be in  
a state where the "right" source will be selected. For example:

<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 at the  
point when the source element is inserted it doesn't have src and type  
set. 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.

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. The parts of the algorithm that actually need to be run  
asynchronously is calling resource fetch (since that waits for the  
network) and step 21, as that waits for either the parser or a script to  
insert a source element and can wait forever.

So, what I'm tentatively suggesting is:

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

2. Instead of calling the resource fetch algorithm in step 5/9, queue a  
task to call it and then return. The failure steps that follow can be  
called explicitly from the resource fetch algorithm.

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

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

-- 
Philip Jägenstedt
Core Developer
Opera Software