W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] Should events be paused on detached iframes?

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Fri, 27 Aug 2010 13:16:30 +0300
Message-ID: <4C77907E.50609@helsinki.fi>
On 08/24/2010 11:38 PM, Adam Barth 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.
One thing not too clear in the "magic iframe" approach is that how
session history works; how is the session history from the iframe
merged to the new one, especially if the iframe moves to a new document.

Another thing, which is more implementation depended problem, is that
how the plugin native widget reparenting works, in case the iframe
uses plugins.


  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:
>> <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:
>> <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
Received on Friday, 27 August 2010 03:16:30 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:26 UTC