Re: [whatwg] Race condition in media load algorithm

[Boris Zbarsky]

On 8/9/10 6:28 AM, Philip Jägenstedt wrote:

Let's focus on how this interacts with the parser, because that probably
changes everything else to fall into place, see below.


OK.


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.


Why?  Maybe if I understood what we're trying to accomplish with the 
synchronous section bit here I'd have a better idea of how it should work...



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.


Agreed so far.


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.


I'd like to pin down why this is the case before even starting to sort 
out the parser behavior, since that depends on the exact goal we're 
trying to achieve.


-Boris

Re: [whatwg] Race condition in media load algorithm

[Philip Jägenstedt]

On Fri, 06 Aug 2010 15:30:42 +0200, Boris Zbarsky  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  
 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):




alert(document.querySelector('video').networkState)

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");
   v.appendChild(s);
   document.body.appendChild(v);
   alert(v.networkState);


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

Re: [whatwg] Race condition in media load algorithm

[Boris Zbarsky]

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



Who said anything about infinite loops?


It's one way of a script not finishing.


OK, sure.  But if a script s busy-looping, I think we all agree that's 
not considered a time when synchronous sections can be run.



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


That's not the case, sadly.  Gecko had to implement them for compat 
reasons, for example.


In any case, modal dialogs are just one place where the issue arises. 
Other situations per current spec that may or may not correspond to 
threads being suspended in your model:


1)  Spinning the event loop while the parser is blocked on a 
that's waiting on stylesheets to load.
2)  Spinning the event loop at parse end waiting for deferred scripts.