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

[Boris Zbarsky]

On 8/10/10 4:40 AM, Philip Jägenstedt wrote:
> 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.

Ah, the waiting state, etc?

Why does the algorithm not just reevaluate any sources after the 
newly-inserted source instead?

> However, scripts can see the state at any point, which is why it needs to be the same in all browsers.

I'm not sure which "the state" you mean here.

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

Right, ok.

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

Well, the problem is that it introduces hysteresis into the DOM.  Why is 
this a smaller consideration than the other, in the edge case when 
someone inserts sources in reverse order and "slowly" (off the event loop)?

That is, why do we only consider sources inserted after the |pointer| 
instead of all newly inserted sources?

> I'm not sure what you mean by hysteresis

http://en.wikipedia.org/wiki/Hysteresis

Specifically, that the state of the page depends not only on the current 
state of the DOM but also on the path in state space that the page took 
to get there.

Or in other words, that inserting two <source> elements does different 
things depending on whether you do "appendChild(a); appendChild(b)" or 
"appendChild(b); insertBefore(a, b)", even though the resulting DOM is 
exactly the same.

Or in your case, the fact that the ordering of the setAttribute and 
insertChild calls matters, say.

Such situations, which introduce order-dependency on DOM operations, are 
wonderful sources of frustration for web developers, especially if 
libraries that abstract away the DOM manipulation are involved (so the 
web developer can't even change the operation order).

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

Yes.  Step 5 in the resource selection algorithm I see is:

   5. Queue a task to fire a simple event named loadstart at the media
      element.

It has no substeps.

> Mozilla is implementing this now. How are you interpreting "await a
> stable state" when the resource selection algorithm is triggered by the
> parser?

At the moment, given that we don't differentiate betwen "pause" and 
"spin the event loop" internally, it sounds like we plan to treat tis as 
"wait until the next event runs from the event loop".  This means we 
will treat an alert being up as being in a stable state; same for sync 
XHR, showModalDialog, etc.  From the parser we will basically treat it 
as "run asynchronously".

> Will the result be 100% predictable or depend on "random" things
> like how much data the parser already has available from the network?

I don't know about "result".  When the algorithm runs, exactly, will 
depend on the amount of data the parser parses before returning to the 
event loop.  Does that affect "result"?

-Boris