[whatwg] Should events be paused on detached iframes?

At least spec tells that if an iframe is detached from the DOM and then
becomes eligible for GC (not hold via JS reference not DOM connection) - it
gets unloaded w/o onunload firing (4.8.2):

On the other hand, if an
iframe<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element>is
removed<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#remove-an-element-from-a-document>from
a
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document>and
is then subsequently garbage collected, this will likely mean (in the
absence of other references) that the child browsing
context<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#child-browsing-context>'s
WindowProxy<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#windowproxy>object
will become eligble for garbage collection, which will then lead to
thatbrowsing context<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context>being
discarded<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#a-browsing-context-is-discarded>,
which will then lead to its
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document>being
discarded<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#discard-a-document>also.
This happens without notice to any scripts running in that
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#document>;
for example, no unload events are fired (the "unload a
document<http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#unload-a-document>"
steps are not run).

Seems there are bugs to fix :-)


On Tue, Aug 24, 2010 at 3:42 PM, Dirk Pranke <dpranke at chromium.org> wrote:

> 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?
>
> The following test illustrates this, and behaves differently in
> webkit, opera, FF, and IE (all of which are different from the spec
> :).
>
> http://nfs.oldkentuckyshark.com/tests/detached_iframes/
>
> -- Dirk
>
> On Tue, Aug 24, 2010 at 3:27 PM, Dmitry Titov <dimich at chromium.org> wrote:
> > 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:
> > var iframe = document.getElementById("test");
> > other_document.adoptNode(iframe);
> > other_document.getElementById("newParent").attachChild(iframe);
> > WebKit has a bug (https://bugs.webkit.org/show_bug.cgi?id=13574) to
> enable
> > moving iframes w/o reloading. FF has a bug on that as well
> > (https://bugzilla.mozilla.org/show_bug.cgi?id=254144) but it's hard to
> say
> > when exactly those will be fixed. I hope to fix WebKit issue at some
> point.
> > 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:
> > Removing an iframe from a Document does not cause its browsing context to
> be
> > discarded. Indeed, an iframe's browsing context can survive its original
> > parent Document if its iframe is moved to another Document.
> >
> > 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.
> > Dmitry
> > On Tue, Aug 24, 2010 at 1:38 PM, Adam Barth <w3c at adambarth.com> wrote:
> >>
> >> This seems related to the "magic iframe" concept that was recently
> >> added in WebKit.  Basically, magic iframe lets you move an iframe from
> >> one document to another without blowing away the JavaScript/DOM state
> >> of the iframe.  The way this works is that the iframe remains "alive"
> >> until the browser returns to the main event loop.  If a living iframe
> >> gets added to a document, then it keeps all it's state.  This feature
> >> is useful for sites like Gmail that have chat windows that can be
> >> opened from the main document.  If the user closes the main document,
> >> the chat windows can adopt some iframe that keeps the proper state.
> >>
> >> Adam
> >>
> >>
> >> On Tue, Aug 24, 2010 at 1:30 PM, Ben Lerner <blerner at cs.washington.edu>
> >> wrote:
> >> >  There seems to be a bit of disagreement among browsers about how
> event
> >> > loops and iframes interact when an iframe is removed and then
> reinserted
> >> > into its parent document.  Consider the following two documents: the
> >> > parent
> >> > document has a button that removes or reattaches an iframe to the
> >> > document,
> >> > while the second simply sets an interval to update the page content.
> >> >
> >> > Page1.html:
> >> > <!DOCTYPE HTML>
> >> > <html>
> >> > <body>
> >> > <p><button onclick="toggleInDoc();">Show/hide</button></p>
> >> > <iframe id="test" src="page2.html"></iframe>
> >> > <script>
> >> >    var test = document.getElementById("test");
> >> >    function toggleInDoc() {
> >> >      if (test.parentNode == null)
> >> >        document.body.appendChild(test);
> >> >      else
> >> >        document.body.removeChild(test);
> >> >    }
> >> > </script>
> >> > </body>
> >> > </html>
> >> >
> >> >
> >> > Page2.html:
> >> > <!DOCTYPE HTML>
> >> > <html>
> >> > <body>
> >> > <p id="test"></p>
> >> > <script>
> >> >    window.setInterval(function() {
> >> > document.getElementById("test").innerHTML
> >> > += "."; }, 500);
> >> > </script>
> >> > </body>
> >> > </html>
> >> >
> >> >
> >> > Assume the user waits until the interval has fired several times, then
> >> > presses the button, waits a while, and presses it again.  There are
> >> > three
> >> > possible outcomes:
> >> > 1. When the iframe is reattached, the inner page reloads.  This seems
> to
> >> > go
> >> > beyond the wording of the spec, which says only "When an iframe
> element
> >> > is
> >> > first inserted into a document, the user agent must create a nested
> >> > browsing
> >> > context, and then process the iframe attributes for the first time."
> >> >  (This
> >> > isn't the first time the iframe is inserted into the document, so we
> >> > shouldn't process the iframe attributes again.)
> >> >
> >> > 2. The interval (and presumably, all events) in the iframe is paused
> >> > while
> >> > it's been detached (since the document is no longer fully active, but
> it
> >> > also has not been discarded because of the global reference to its
> >> > container
> >> > element).
> >> >
> >> > 3. The interval (and presumably, all events) continues to fire while
> >> > it's
> >> > been detached, and the content of page2 will have changed while it's
> >> > been
> >> > detached from page1.
> >> >
> >> > So far, Chrome 6, Opera 10.6 and Firefox 3.6 follow #1, and IE 8
> follows
> >> > #3.
> >> >  My reading of the "fully active" clause of the spec leads me to
> expect
> >> > #2.
> >> >  Which of these behaviors is the desired one?  And/or, would it be
> >> > desirable
> >> > to permit authors to specify which behavior they intend?
> >> >
> >> > Thanks,
> >> > ~ben
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100824/f966ae18/attachment-0001.htm>

Received on Tuesday, 24 August 2010 15:59:24 UTC