<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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... :)<br>
<br>
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?<br>
<br>
To stretch an analogy a bit: detaching an iframe, saving a reference
to it, and then attaching it/adopting it later to another document
is a bit like using DVR to record the rest of a TV show to watch
later: I should get the same show, paused wherever I left off
watching it, on whatever TV is convenient for me to watch it on. I
shouldn't have to immediately start watching on the second screen in
order to preserve state, and it shouldn't keep playing while I move
from one screen to the other :)<br>
<br>
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 :)<br>
<br>
On 8/24/2010 3:42 PM, Dirk Pranke wrote:
<blockquote
cite="mid:AANLkTikyeBVh-=4vuwnoPPbmPvS=W2kSrCZ1U2BG36C7@mail.gmail.com"
type="cite">
<pre wrap="">On a related note, the behavior of onUnload in this situation is quite
unclear. Should onUnload() fire if an iframe is detached from the DOM?
</pre>
</blockquote>
Indeed -- it seems to me from the spec that it should not fire,
until (following the snippet Dmitry quoted below) the last reference
to the iframe is dropped and therefore the browsing context can be
discarded.<br>
<br>
I'm not sure the adoptNode workaround mentioned in the bugs below is
a full fix. It gets us from behavior #1 to behavior #3, but doesn't
consider #2 as a possibility. Certainly some loose ends to think
about...<br>
<br>
~ben<br>
<br>
On 8/24/2010 3:27 PM, Dmitry Titov wrote:
<blockquote
cite="mid:AANLkTinCrvEZkhvmKiTKnD8Hh2wpUZ+3obPPHp-p0ynH@mail.gmail.com"
type="cite">Indeed, in WebKit you normally see #1 (iframe
unloads). We have added the ability to move 'live' iframe, as Adam
mentions, potentially across documents, while keeping it
completely alive, with XHRs loading, events firing etc (aka 'magic
iframe' feature). One would need to use adoptNode() API to do
that, something like:
<div>
<br>
</div>
<div>var iframe = document.getElementById("test");</div>
<div>other_document.adoptNode(iframe);</div>
<div>other_document.getElementById("newParent").attachChild(iframe);</div>
<div><br>
</div>
<div>
WebKit has a bug (<a moz-do-not-send="true"
href="https://bugs.webkit.org/show_bug.cgi?id=13574">https://bugs.webkit.org/show_bug.cgi?id=13574</a>)
to enable moving iframes w/o reloading. FF has a bug on that as
well (<a moz-do-not-send="true"
href="https://bugzilla.mozilla.org/show_bug.cgi?id=254144">https://bugzilla.mozilla.org/show_bug.cgi?id=254144</a>)
but it's hard to say when exactly those will be fixed. I hope to
fix WebKit issue at some point.</div>
<div><br>
</div>
<div>While discussing 'magic iframe', Ian Hickson pointed out that
nothing in the spec actually mandates discarding the live
document inside iframe simply because it's iframe element is
connected/disconnected to DOM of the parent document. Here is a
note from the HTML5 spec about that: </div>
<div><span class="Apple-style-span" style="font-family:
sans-serif,'Droid Sans Fallback'; font-size: medium; color:
rgb(0, 128, 0); font-style: italic; font-weight: bold;
line-height: 21px;"><a moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#remove-an-element-from-a-document"
title="remove an element from a document" style="color:
rgb(0, 0, 204); background-color: transparent;">Removing</a> an <code
style="font-size: inherit; font-family: monospace,'Droid
Sans Fallback',sans-serif; font-variant: normal; color:
rgb(255, 69, 0);"><a moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element"
style="color: inherit; background-color: transparent;">iframe</a></code> from
a <code style="font-size: inherit; font-family:
monospace,'Droid Sans Fallback',sans-serif; font-variant:
normal; color: rgb(255, 69, 0);"><a moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document"
style="color: inherit; background-color: transparent;">Document</a></code> does
not cause its <a moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context"
style="color: rgb(0, 0, 204); background-color:
transparent;">browsing context</a> to be discarded. Indeed,
an <code style="font-size: inherit; font-family:
monospace,'Droid Sans Fallback',sans-serif; font-variant:
normal; color: rgb(255, 69, 0);"><a moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element"
style="color: inherit; background-color: transparent;">iframe</a></code>'s <a
moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context"
style="color: rgb(0, 0, 204); background-color:
transparent;">browsing context</a> can survive its original
parent <code style="font-size: inherit; font-family:
monospace,'Droid Sans Fallback',sans-serif; font-variant:
normal; color: rgb(255, 69, 0);"><a moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document"
style="color: inherit; background-color: transparent;">Document</a></code> if
its <code style="font-size: inherit; font-family:
monospace,'Droid Sans Fallback',sans-serif; font-variant:
normal; color: rgb(255, 69, 0);"><a moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element"
style="color: inherit; background-color: transparent;">iframe</a></code> is
moved to another <code style="font-size: inherit; font-family:
monospace,'Droid Sans Fallback',sans-serif; font-variant:
normal; color: rgb(255, 69, 0);"><a moz-do-not-send="true"
href="http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document"
style="color: inherit; background-color: transparent;">Document</a></code>.</span><br>
<br>
</div>
<div>So it seems the right behavior is to keep the content alive.
It's not clear why the events would not fire during DOM
operations though. Perhaps they should, since nothing is
changing from the perspective of the document loaded into iframe
- for example, XHR probably should continue loading content if
it was doing so before iframe was disconnected from its parent
node. Doing some suspension (as for example is done when a page
goes into back-forward cache?) would be way more complex
mechanism to have, with necessary events on pause/unpause so the
live document could re-start async operations correctly.</div>
<div><br>
</div>
<div>Dmitry</div>
<div><br>
<div class="gmail_quote">On Tue, Aug 24, 2010 at 1:38 PM, Adam
Barth <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:w3c@adambarth.com">w3c@adambarth.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
This seems related to the "magic iframe" concept that was
recently<br>
added in WebKit. Basically, magic iframe lets you move an
iframe from<br>
one document to another without blowing away the
JavaScript/DOM state<br>
of the iframe. The way this works is that the iframe
remains "alive"<br>
until the browser returns to the main event loop. If a
living iframe<br>
gets added to a document, then it keeps all it's state.
This feature<br>
is useful for sites like Gmail that have chat windows that
can be<br>
opened from the main document. If the user closes the main
document,<br>
the chat windows can adopt some iframe that keeps the proper
state.<br>
<br>
Adam<br>
<br>
<br>
On Tue, Aug 24, 2010 at 1:30 PM, Ben Lerner <<a
moz-do-not-send="true"
href="mailto:blerner@cs.washington.edu">blerner@cs.washington.edu</a>>
wrote:<br>
> There seems to be a bit of disagreement among browsers
about how event<br>
> loops and iframes interact when an iframe is removed
and then reinserted<br>
> into its parent document. Consider the following two
documents: the parent<br>
> document has a button that removes or reattaches an
iframe to the document,<br>
> while the second simply sets an interval to update the
page content.<br>
><br>
> Page1.html:<br>
> <!DOCTYPE HTML><br>
> <html><br>
> <body><br>
> <p><button
onclick="toggleInDoc();">Show/hide</button></p><br>
> <iframe id="test"
src="page2.html"></iframe><br>
> <script><br>
> var test = document.getElementById("test");<br>
> function toggleInDoc() {<br>
> if (test.parentNode == null)<br>
> document.body.appendChild(test);<br>
> else<br>
> document.body.removeChild(test);<br>
> }<br>
> </script><br>
> </body><br>
> </html><br>
><br>
><br>
> Page2.html:<br>
> <!DOCTYPE HTML><br>
> <html><br>
> <body><br>
> <p id="test"></p><br>
> <script><br>
> window.setInterval(function() {
document.getElementById("test").innerHTML<br>
> += "."; }, 500);<br>
> </script><br>
> </body><br>
> </html><br>
><br>
><br>
> Assume the user waits until the interval has fired
several times, then<br>
> presses the button, waits a while, and presses it
again. There are three<br>
> possible outcomes:<br>
> 1. When the iframe is reattached, the inner page
reloads. This seems to go<br>
> beyond the wording of the spec, which says only "When
an iframe element is<br>
> first inserted into a document, the user agent must
create a nested browsing<br>
> context, and then process the iframe attributes for the
first time." (This<br>
> isn't the first time the iframe is inserted into the
document, so we<br>
> shouldn't process the iframe attributes again.)<br>
><br>
> 2. The interval (and presumably, all events) in the
iframe is paused while<br>
> it's been detached (since the document is no longer
fully active, but it<br>
> also has not been discarded because of the global
reference to its container<br>
> element).<br>
><br>
> 3. The interval (and presumably, all events) continues
to fire while it's<br>
> been detached, and the content of page2 will have
changed while it's been<br>
> detached from page1.<br>
><br>
> So far, Chrome 6, Opera 10.6 and Firefox 3.6 follow #1,
and IE 8 follows #3.<br>
> My reading of the "fully active" clause of the spec
leads me to expect #2.<br>
> Which of these behaviors is the desired one? And/or,
would it be desirable<br>
> to permit authors to specify which behavior they
intend?<br>
><br>
> Thanks,<br>
> ~ben<br>
><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
</body>
</html>