[whatwg] Race condition in media load algorithm

Mon Aug 9 03:28:33 PDT 2010

On Fri, 06 Aug 2010 15:30:42 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/6/10 4:04 AM, Philip Jägenstedt wrote:
>>> See, this concept of "a script" is a funny one, given that scripts are
>>> reentrant, and that multiple different scripts can all be running at
>>> the same time, possibly with event loops nested in between on the
>>> conceptual callstack
>>
>> Well, what we really look at is an execution thread. When a script
>> triggers a synchronous event handler or is otherwise suspended while
>> waiting for another thread to finish, we will wait for the "outermost"
>> suspended thread to finish executing. So, yeah, it's not completely
>> trivial :)
>
> That really doesn't sound like it maps well to the proposed HTML5 spec,  
> for what it's worth...  Of course it sounds like you're suggesting the  
> spec should be changed (without actually describing your changes in  
> speccable non-implementation-specific terms).

The "await a stable state" concept was introduced in  
<http://html5.org/tools/web-apps-tracker?from=3461&to=3462> and is used  
only for media elements. I can't remember any discussion about the change  
in async behavior at the time, so didn't think much of it. It's because  
Mozilla are implementing this now that the issue has surfaced, so let's  
try to find a solution that's implementable in all browsers. Let's focus  
on how this interacts with the parser, because that probably changes  
everything else to fall into place, see below.

>>> It's possible that it can't. It would depend on the exact steps that
>>> run in the synchronous section, but since synchronous sections can't
>>> trigger script it might not be detectable at all.
>>
>> The most important things is that the following always alert 3
>> (NETWORK_NO_SOURCE):
>>
>> <!doctype html>
>> <video>
>> <source>
>> <script>alert(document.querySelector('video').networkState)</script>
>>
>> In other words, the synchronous section must at the latest be run just
>> before running an inline script.
>
> OK, let's focus on the issue at hand; I agree that we're more likely to  
> get somewhere with that than with generalities.  What about this case:
>
> <script>
>    var v = document.createElement("video");
>    var s = document.createElement("source");
>    v.appendChild(s);
>    document.body.appendChild(v);
>    alert(v.networkState);
> </script>
>
> Should this also run the synchronous section before returning from the  
> appendChild call, even though there's a script active?  If so, how does  
> that fit in with your proposal?  If not, how is this different from your  
> example?

Whether it's the parser or a script that triggers the resource selection  
algorithm, it is run up to step 2 where it's supposed to await a stable  
state. Actually, my example is bad because networkState is set to  
NETWORK_NO_SOURCE is step 1. What's actually interesting is when one can  
see the side-effects of the synchronous section running, e.g. by  
networkState being set to NETWORK_LOADING.

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. If  
that's accomplished by waiting until the thread has finished or by means  
of the event loop isn't important as long as it's implementable and the  
result is 100% predictable. Modulo the effects of modal dialogs and other  
corner-cases, networkState should remain at NETWORK_NO_SOURCE for the  
remainder of the script that triggered resource selection.

Parsing then. I don't know the parser section very well, but it doesn't  
mention "task", so I'm guessing that running it isn't considered a task  
itself. I can't find anything to suggest that the parser inserting a  
script element would cause synchronous sections to run before the script  
is executed. What then, does "await a stable" state amount to? Just  
running it the next time the event loop spins would appear to give rather  
random results, right?

The parser example above alerts 0 or 3 depending on whether the sync  
section has run. Opera alerts 3, as the sync section is run at the same  
time the source element is inserted by the parser. If that's not the right  
thing to do, what is?

-- 
Philip Jägenstedt
Core Developer
Opera Software