[whatwg] Race condition in media load algorithm
philipj at opera.com
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
>> <!doctype html>
>> 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:
> var v = document.createElement("video");
> var s = document.createElement("source");
> 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
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?
More information about the whatwg