[whatwg] Race condition in media load algorithm

[Philip Jägenstedt]

On Wed, 04 Aug 2010 19:19:35 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 8/4/10 6:56 AM, Philip Jägenstedt wrote:
>> On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky <bzbarsky at mit.edu>  
>> wrote:
>>
>>> On 8/4/10 4:29 AM, Philip Jägenstedt wrote:
>>>> That could be, but is this behavior actually useful for anything? It's
>>>> certainly simpler to implement and more predictable for authors to
>>>> always wait until the current script has finished executing.
>>>
>>> 1) That requires defining "current script".
>>
>> OK, but that's just a spec problem. It's trivial in implementation
>> because when the resource selection algorithm was is triggered by a
>> script, you can just pass along a reference to that very script.
>
> 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.

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

>>> 2) Who said it will ever finish executing?
>>
>> 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 and video then not  
working would be fine as long as all browsers break in the same way. If a  
script is showing a modal dialog, not loading a video in the background  
seems fine. Other than possible implementation difficulties, why would it  
matter?

>> Is there any valid case for a script never finishing?
>
> Yes, it could showModalDialog and the user could spend several hours  
> interacting with it.
>
>> 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. Is there anything that sites actually use that could make  
the difference in implementation visible? I truly doubt we'll see any  
serious compat issues because of showModalDialog...

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, because that would slow down  
the time to load <video> considerably. If it just means letting the parser  
finish its current batch of input, I can't see how black-box testing could  
tell the difference between this and always ignoring the "await a stable  
state" step, as the parser could just happen to run for exactly that long.  
Always triggering the steps of the resource selection algorithm  
immediately is certainly more predictable, and the spec as written works  
well when doing so.

-- 
Philip Jägenstedt
Core Developer
Opera Software