[whatwg] Should events be paused on detached iframes?

[Ben Lerner]

On 8/24/2010 7:50 PM, Boris Zbarsky wrote:
> 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).
I assume such mutation could only come from other, fully-active, 
same-origin documents.  Why should mutating the document cause it to be 
thrown away?  Because if the document had handlers on it to detect 
mutations and they didn't run, the document could get corrupted?

Suppose, for a hypothetical, that instead of throwing away the 
hibernated document, you returned an error on the DOM method in the 
caller document if it tried to mutate it.  I.e., it is an error to 
mutate a hibernated document, punishable by a JS exception.  But reading 
the document could be ok.  Would that design be plausible, irrelevant, 
or outright broken?  (I'm still trying to get a handle on the rationale 
behind either reloading or not pausing documents, beyond just 
"historical reasons", so I'm just brainstorming here...)
> 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.  ;)
Fair enough.  My current understanding is that a nested document has a 
pointer to its browsing context which has a pointer to its container 
iframe element, which has an owner document which ...eventually... has a 
pointer to the top-level browsing context.  So there exists a pointer 
chain that could work; making it actually work might be finicky. :)
>
>> 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.
>
And ties in to my understanding above: an event handler always has some 
notion of a window object, perhaps indirectly, which in turn has a 
pointer chain through to various documents.  So the UA could determine 
which document was responsible for the alert, but that determination 
would have no visual/intuitive explanation for the user.
>> 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...
That's a tunable policy issue, right?  I.e., buffer X Kb of data, then 
terminate active network requests.  Maybe even be so kind as to fake up 
a pair of offline/online events.  A web program probably has to be 
robust to these sorts of network-partitioning events anyway, right?

Thanks,
~ben