[whatwg] Should events be paused on detached iframes?

On 8/24/10 7:09 PM, Ben Lerner wrote:
>   The history navigation analogy is a good one: pages presumably already
> have to handle the pageshow event to deal with being revived from the
> history, and the browser already needs to know how to fire that event.
> Why not reuse those mechanisms? A strawman claim: Nothing may be
> changing from the perspective of the iframe, but it certainly is
> changing from the perspective of the container or the user: detaching an
> iframe from a page is like navigating a browsing context away from a
> page, putting it into hibernation until it's reattached to an active
> document/browsing context. What subtle or important facet of the web am
> I missing that breaks this analogy? (It wouldn't surprise me if I missed
> something obvious, either... :)

At least in the case of Gecko, there are at least the following things 
to keep in mind:

1) "hibernating" documents are very limited in what one can do with
    them (e.g. attempting to mutate the document in any way while
    hibernating will throw it away).
2) Documents have security policies applied to them based on the
    toplevel content window (or browser tab, if you prefer to think
    about it) they're associated with.  Which means that allowing
    documents not immediately associated with any toplevel window,
    which would be the case right now in Gecko for an <iframe> not in
    a document, leads to security problems.  This could be changed by
    redoing how the association is implemented, but there's some
    touchy code involved that we'd rather not get wrong.  ;)

> Another reason to consider suspending detached iframes: suppose that in
> the chat window example below, the iframe wasn't just a same-origin
> place to store global state, but also had its own UI, with callbacks and
> event handlers and whatnot. If, during the interim while the iframe was
> being detached, adopted and reattached, that frame executed a timer that
> popped up a modal alert or prompt to the user, how would the user
> reasonably know where that alert came from? And what document(s?) should
> be paused while the alert is shown?

And for that matter, how would the UA know where the alert came from, in 
terms of correctly parenting it?  This ties back to item #2 above.

> Regarding XHR and such -- I guess what I'm suggesting is suspending the
> event loop, but not necessarily suspending asynch processes. So XHR can
> continue to queue tasks; media can continue to buffer; resources can
> continue to load. When the document is reattached, it finds itself with
> a backlog of events to handle, which is the exact same situation as a
> very bursty network connection :)

Note that in Gecko documents with active network requests never go into 
hibernation right now, precisely because we don't want to have to buffer 
potentially-arbitrary amounts of data (see JPEG push) for arbitrary 
lengths of time.  We still wouldn't want to do so in this case...

-Boris

Received on Tuesday, 24 August 2010 19:50:10 UTC