On Wed, 04 Aug 2010 19:19:35 +0200, Boris Zbarsky <[email protected]> wrote:
On 8/4/10 6:56 AM, Philip Jägenstedt wrote:
On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky <[email protected]>
wrote:
On 8/4/10 4:29 AM, Philip Jägenstedt wrote:
That could be, but is this behavior actually useful for anything? It's
certainly simpler to implement and more predictable for authors to
always wait until the current script has finished executing.
1) That requires defining "current script".
OK, but that's just a spec problem. It's trivial in implementation
because when the resource selection algorithm was is triggered by a
script, you can just pass along a reference to that very script.
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.
(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.)
2) Who said it will ever finish executing?
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 and video then not
working would be fine as long as all browsers break in the same way. If a
script is showing a modal dialog, not loading a video in the background
seems fine. Other than possible implementation difficulties, why would it
matter?
Is there any valid case for a script never finishing?
Yes, it could showModalDialog and the user could spend several hours
interacting with it.
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. Is there anything that sites actually use that could make
the difference in implementation visible? I truly doubt we'll see any
serious compat issues because of showModalDialog...
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, because that would slow down
the time to load <video> considerably. If it just means letting the parser
finish its current batch of input, I can't see how black-box testing could
tell the difference between this and always ignoring the "await a stable
state" step, as the parser could just happen to run for exactly that long.
Always triggering the steps of the resource selection algorithm
immediately is certainly more predictable, and the spec as written works
well when doing so.
--
Philip Jägenstedt
Core Developer
Opera Software
