On Fri, 06 Aug 2010 15:30:42 +0200, Boris Zbarsky <bzbar...@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
(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?
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?
--
Philip Jägenstedt
Core Developer
Opera Software
