[whatwg] Race condition in media load algorithm

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.

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

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

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

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

-Boris

Received on Thursday, 5 August 2010 08:22:17 UTC