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
