[whatwg] Should events be paused on detached iframes?

Fri Aug 27 03:16:30 PDT 2010

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.

-Olli

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