- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 05 Aug 2010 11:14:31 +0200
On Wed, 04 Aug 2010 19:19:35 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 8/4/10 6:56 AM, Philip J?genstedt wrote: >> On Wed, 04 Aug 2010 11:32:51 +0200, Boris Zbarsky <bzbarsky at mit.edu> >> 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
Received on Thursday, 5 August 2010 02:14:31 UTC