[whatwg] Race condition in media load algorithm

Fri Aug 6 06:30:42 PDT 2010

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

>> Who said anything about infinite loops?
>
> It's one way of a script not finishing.

OK, sure.  But if a script s busy-looping, I think we all agree that's 
not considered a time when synchronous sections can be run.

>>> If a script is showing a modal dialog, not loading a video in the
>>> background seems fine.
>>
>> Why? It doesn't seem fine to me at all.
>
> My point is that no one uses modal dialogues

That's not the case, sadly.  Gecko had to implement them for compat 
reasons, for example.

In any case, modal dialogs are just one place where the issue arises. 
Other situations per current spec that may or may not correspond to 
threads being suspended in your model:

1)  Spinning the event loop while the parser is blocked on a <script>
     that's waiting on stylesheets to load.
2)  Spinning the event loop at parse end waiting for deferred scripts.

that seems to be it; the remaining cases are pauses in the spec.  That 
said, I still think the behavior of pause (which you're proposing for 
showModalDialog as well, I think) makes no sense; I'd much rather have 
the showModalDialog behavior for things like sync XHR, alerts, etc.

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

-Boris