<!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>