[whatwg] <video> loading algorithms

[Philip Jägenstedt]

On Tue, 24 Aug 2010 10:24:35 +0200, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 26 Jul 2010, Philip Jägenstedt wrote:
>>
>> Looking again at the resource selection algorithm, the second step is to
>> await a stable state, i.e. wait until the current script has finished.
>
> Not necessarily finished. The idea is just that the resource selection
> algorithm might run on another thread, and the way the spec is written
> allows the UA to synchronise at very predictable points (e.g. when
> showModalDialag() is invoked, or when the HTML parser isn't inserting
> elements, or while waiting for a style sheet to load so that a <script>
> can be run).

OK, I hadn't really understood "await a stable state".

>> Given that, it wouldn't be a big problem to let modification of src
>> attributes on source elements trigger resource selection, you won't get
>> the 3-2-1 problem I mentioned earlier.
>
> I don't really understand what use case this would solve.

Neither do I, I'm just saying that it's easy to do if necessary.

> On Tue, 3 Aug 2010, Philip Jägenstedt wrote:
>>
>> For the record, here's how I interpreted "await a stable state":
>>
>> The only state that is not stable is a running script.
>
> Any running task is "not stable", not just running script. For example,
> you shouldn't run a synchronous section while the parser is adding
> elements to the DOM.
>
>
>> The only step in any video-related algorithm one can reach from a script
>> is step 2 of the resource selection algorithm. Therefore, when reaching
>> that step, if the resource selection algorithm was triggered by a
>> script, wait until that script has finished and then continue. The only
>> somewhat tricky part is that if we are in an event handler triggered by
>> script, we should wait until the script that triggered the event handler
>> has finished. The only way I know of triggering this corner case is by
>> invoking a synchronous event handler from script, e.g. by calling
>> click().
>>
>> All other occurrences of "await a stable state" I've ignored as we can't
>> not be in a stable state when reaching them.
>
> Sure you can. The rest of the algorithm is asynchronous, so a script  
> could
> have started when you reach them. Or the parser could be adding elements,
> or you could be handling incoming network traffic in a way that affects
> the DOM (e.g. EventSource could be about to fire an event), etc.

OK, thanks for pointing this out. If in the end no spec change is required  
I'll file a bug on Opera.

> On Mon, 9 Aug 2010, Philip Jägenstedt wrote:
>>
>> 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.
>
> It is. Each task that the networking task source places on the task queue
> while the fetching algorithm runs must then fill the parser's input  
> stream
> with the fetched bytes and cause the HTML parser to perform the
> appropriate processing of the input stream.
>
>
>> 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.
>
> Can cause. Step 3 of the Otherwise clause at the end of the "An end tag
> whose tag name is "script"" section of The "text" insertion mode.

OK, this is what I wanted to see. Should this step be read as

while (there is no style sheet blocking scripts and the script's "ready to  
be parser-executed" flag is set) {
   Spin the event loop
}

or

do {
   Spin the event loop
} while (there is no style sheet blocking scripts and the script's "ready  
to be parser-executed" flag is set)

?

In other words, will the synchronous section always be 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?
>
> How so?
>
>> The parser example above alerts 0 or 3 depending on whether the sync
>> section has run.
>
> It should always alert 3. The networkState is set _before_ the sync
> section runs.
>
>> 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?
>
> The sync section runs whenever the parser decides it's time to run it --
> conceptually, you can treat any sequence of bytes processed by the parser
> in an uninterrupted fashion as a task.

I'm not an expert on parsing, but assume that how long the parser runs  
depends on how much data is available from the network. However, if the  
event loop always spins when encountering </script> that wouldn't matter,  
so let's clear that up first.

> On Mon, 9 Aug 2010, Philip Jägenstedt wrote
>>
>> So, what I'm tentatively suggesting is:
>>
>> 1. Remove the "await a stable state" concept and just continue running
>> the steps that follow it. (This is what Opera does now when resource
>> selection is triggered by the parser, as I have no idea how long to wait
>> otherwise.)
>
> This would introduce race conditions, so that's not really a good idea.
>
>
> On Mon, 9 Aug 2010, Philip Jägenstedt wrote:
>>
>> 2. Instead of calling the resource fetch algorithm in step 6/9, queue a
>> task to call it and then return. The failure steps that follow can be
>> called explicitly from the resource fetch algorithm.
>
> That would potentially make things much slower. What's the advantag?

It would be collateral damage from removing "await a stable state", but if  
"await a stable state" turns out to not depend on network randomness then  
of course I'd prefer to change nothing.

> On Wed, 11 Aug 2010, Philip Jägenstedt wrote:
>>
>> [...] would result in disasters like this:
>>
>> <!doctype html>
>> <video src="video.webm"></video>
>> <!-- network packet boundary or lag? -->
>> <script>alert(document.querySelector('video').networkState)</script>
>>
>> The result will be 0 (NETWORK_EMPTY) or 2 (NETWORK_LOADING) depending on
>> whether or not the parser happened to return to the event loop before
>> the script.
>
> What it returns depends entirely on what happened when you fetched
> video.webm, so it's not really possible to tell. This isn't a disaster,
> you can do the same with, e.g., <img src=""> -- will its .complete be
> true or not?

I think I meant to say that it if the synchronous section has run depends  
on "whether or not the parser happened to return to the event loop before  
the script". In other words, networkState could be NETWORK_NO_SOURCE,  
NETWORK_EMPTY or NETWORK_LOADING here. Hopefully all my conclusions are  
incorrect and there's actually a guarantee that the synchronous sections  
runs before any scripts execute, see above.

-- 
Philip Jägenstedt
Core Developer
Opera Software