On Tue, 24 Aug 2010 10:24:35 +0200, Ian Hickson <[email protected]> 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
