[whatwg] Should events be paused on detached iframes?

[Dmitry Titov]

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-0002.htm>