[whatwg] Race condition in media load algorithm

On Thu, 05 Aug 2010 17:22:17 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/5/10 5:14 AM, Philip J?genstedt wrote:
>>> It's not, in fact, trivial in implementation. You're making
>>> assumptions about how implementations work that don't seem warranted
>>> (e.g. the concept of "reference to that very script" is not
>>> well-defined in some implementations). In particular, what you're
>>> proposing is not at all trivial in Gecko.
>>
>>  From <https://bugzilla.mozilla.org/show_bug.cgi?id=485288#c7> it sounds
>> like Gecko actually has pretty much the same tools to work with as
>> Opera: a nsIThreadObserver that allows you to wait until you've
>> "finished the task in which some JS called load()". This is exactly what
>> Opera does.
>
> No, what Gecko has is an nsIThreadObserver which is notified when an  
> event is processed.  This as nothing with any particular event  
> finishing, and will get called in the "pause" and "spin event loop"  
> states that are defined in the spec.  It does not allow you to wait for  
> a particular task to finish.
>
> Furthemore, tasks do not map to "scripts" very well, either in Gecko or  
> in general.

OK, fair enough.

>> (It's difficult for Opera to rely on the message loop to resume the
>> synchronous section, because our script engine can suspend and continue
>> executing on a later message. Therefore, waiting for a script to finish
>> executing is the best solution.)
>
> 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 :)

>>>> If it doesn't, just don't ever continue with the synchronous section.
>>>
>>> I don't think that's reasonable.
>>
>> A script that's stuck in an infinite loop is broken
>
> Who said anything about infinite loops?

It's one way of a script not finishing.

>> 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, so what happens doesn't  
really matter as long as it is consistent. Let's do what makes the most  
sense implementation-wise and spec-wise and let the result be whatever it  
turns out to be.

>>>> It would block all event handlers from running too
>>>
>>> I believe this is false in the case of showModalDialog.
>>
>> It sounds like we're going to end up with slightly incompatible
>> implementations.
>
> Well, neither one of us is implementing what the spec calls for (in  
> different ways), so... ;)
>
>> A far more important issue is still what to do while the parser is
>> running and we should "await a stable state". It can't possibly mean
>> waiting until the parser has completely finished running
>
> Indeed, no.  However I would assume that a "stable state" in that  
> situation would, for example, imply that the DOM is in a self-consistent  
> state.  So if you start the load algorithm when a <video> is inserted in  
> the document, it has to be after the insertion is fully processed or  
> some such...
>
> In practice, what Gecko would likely do here is to treat "stable state"  
> as "the event loop is spinning", just like we would for the other case.  
>   This means that while a modal dialog is up, or a sync XHR is running  
> or whatnot is a stable state.
>
>> If it just means
>> letting the parser finish its current batch of input
>
> I would assume it does.
>
>> I can't see how
>> black-box testing could tell the difference between this and always
>> ignoring the "await a stable state" step
>
> 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.

-- 
Philip J?genstedt
Core Developer
Opera Software

Received on Friday, 6 August 2010 01:04:32 UTC