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
