On Thu, 05 Aug 2010 17:22:17 +0200, Boris Zbarsky <bzbar...@mit.edu> wrote:
On 8/5/10 5:14 AM, Philip Jägenstedt wrote:
It's not, in fact, trivial in implementation. You're making
assumptions about how implementations work that don't seem warranted
(e.g. the concept of "reference to that very script" is not
well-defined in some implementations). In particular, what you're
proposing is not at all trivial in Gecko.
From <https://bugzilla.mozilla.org/show_bug.cgi?id=485288#c7> it sounds
like Gecko actually has pretty much the same tools to work with as
Opera: a nsIThreadObserver that allows you to wait until you've
"finished the task in which some JS called load()". This is exactly what
Opera does.
No, what Gecko has is an nsIThreadObserver which is notified when an
event is processed. This as nothing with any particular event
finishing, and will get called in the "pause" and "spin event loop"
states that are defined in the spec. It does not allow you to wait for
a particular task to finish.
Furthemore, tasks do not map to "scripts" very well, either in Gecko or
in general.
OK, fair enough.
(It's difficult for Opera to rely on the message loop to resume the
synchronous section, because our script engine can suspend and continue
executing on a later message. Therefore, waiting for a script to finish
executing is the best solution.)
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 :)
If it doesn't, just don't ever continue with the synchronous section.
I don't think that's reasonable.
A script that's stuck in an infinite loop is broken
Who said anything about infinite loops?
It's one way of a script not finishing.
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, so what happens doesn't
really matter as long as it is consistent. Let's do what makes the most
sense implementation-wise and spec-wise and let the result be whatever it
turns out to be.
It would block all event handlers from running too
I believe this is false in the case of showModalDialog.
It sounds like we're going to end up with slightly incompatible
implementations.
Well, neither one of us is implementing what the spec calls for (in
different ways), so... ;)
A far more important issue is still what to do while the parser is
running and we should "await a stable state". It can't possibly mean
waiting until the parser has completely finished running
Indeed, no. However I would assume that a "stable state" in that
situation would, for example, imply that the DOM is in a self-consistent
state. So if you start the load algorithm when a <video> is inserted in
the document, it has to be after the insertion is fully processed or
some such...
In practice, what Gecko would likely do here is to treat "stable state"
as "the event loop is spinning", just like we would for the other case.
This means that while a modal dialog is up, or a sync XHR is running
or whatnot is a stable state.
If it just means
letting the parser finish its current batch of input
I would assume it does.
I can't see how
black-box testing could tell the difference between this and always
ignoring the "await a stable state" step
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.
--
Philip Jägenstedt
Core Developer
Opera Software
