[whatwg] Should events be paused on detached iframes?

[James May]

On 25 August 2010 12:50, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> 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.
>
>
>
Couldn't the iframe be kept alive, but remain "associated" with it's parent
browsing context until (if) it was re-parented / inserted into a different
document. (does this match what other elements in the DOM behave in terms of
event handlers when they are detached?)

That way, complex "hibernate" would be uneeded and it would be clear as to
how to handle events, security, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100826/ddb62a79/attachment-0002.htm>