Moving an iframe in the DOM

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Moving an iframe in the DOM

John J Barton
The HTML5 spec has:

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

To me this statement is ambiguous, since we don't know what 'not ...
discarded' or "survive' means.  Does 'survive' mean that the values in
the browsing context remain intact?  If the context were to say issue
setInterval based computations, would these continue?

I am doing the equivalent of:
  document.body.appendChild(iframe);
  // sometime after the load event:
  anotherElement.appendChild(iframe);

The second appendChild should remove the iframe element from the
document and then insert it under anotherElement. And it does.

However the properties of the window object that I set are not retained.

If I look at the value of iframe.contentWindow.editorInterface before
the second appendChild(), it has the values I defined in the iframe.

If I look at the value after the second appendChild() it is 'undefined'.

I can't tell from the spec if this is a bug or not. Do we know?

jjb

Reply | Threaded
Open this post in threaded view
|

Re: Moving an iframe in the DOM

T.J. Crowder
FWIW, I would suggest that if the spec is ambiguous on it, it should be updated such that the ambiguity is resolved in favor of the behavior you're seeing being a bug. IMHO, the properties you've set on the iframe's window object should be retained.
--
T.J. Crowder
Independent Software Engineer
[hidden email]


On 16 March 2012 05:31, John J Barton <[hidden email]> wrote:
The HTML5 spec has:

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

To me this statement is ambiguous, since we don't know what 'not ...
discarded' or "survive' means.  Does 'survive' mean that the values in
the browsing context remain intact?  If the context were to say issue
setInterval based computations, would these continue?

I am doing the equivalent of:
 document.body.appendChild(iframe);
 // sometime after the load event:
 anotherElement.appendChild(iframe);

The second appendChild should remove the iframe element from the
document and then insert it under anotherElement. And it does.

However the properties of the window object that I set are not retained.

If I look at the value of iframe.contentWindow.editorInterface before
the second appendChild(), it has the values I defined in the iframe.

If I look at the value after the second appendChild() it is 'undefined'.

I can't tell from the spec if this is a bug or not. Do we know?

jjb


Reply | Threaded
Open this post in threaded view
|

Re: Moving an iframe in the DOM

Simon Pieters-3
In reply to this post by John J Barton
On Fri, 16 Mar 2012 05:31:08 +0100, John J Barton  
<[hidden email]> wrote:

> The HTML5 spec has:
>
> "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."

This is just a statement of fact, not a requirement. The spec would mean  
the same thing (i.e. have the same normative requirements) if this text  
was removed. If it were to be discarded, there would need to be a  
requirement saying to discard it when the iframe is removed, or some such,  
I think.

> To me this statement is ambiguous, since we don't know what 'not ...
> discarded' or "survive' means.  Does 'survive' mean that the values in
> the browsing context remain intact?  If the context were to say issue
> setInterval based computations, would these continue?

Let's see.

http://www.whatwg.org/specs/web-apps/current-work/multipage/timers.html#dom-windowtimers-setinterval

"Wait: If the method context is a Window object, wait until the Document  
associated with the method context has been fully active for a further  
interval milliseconds (not necessarily consecutively).
...
Queue the task task."

If the new document the iframe is moved to is also fully active, then  
setInterval would continue normally. If it isn't (e.g. because it doesn't  
have a browsing context), then the setInterval would hang on the waiting  
step.

> I am doing the equivalent of:
>   document.body.appendChild(iframe);
>   // sometime after the load event:
>   anotherElement.appendChild(iframe);
>
> The second appendChild should remove the iframe element from the
> document and then insert it under anotherElement. And it does.
>
> However the properties of the window object that I set are not retained.

The spec doesn't say to remove properties of the window when moving an  
iframe, so that would be a bug.

> If I look at the value of iframe.contentWindow.editorInterface before
> the second appendChild(), it has the values I defined in the iframe.
>
> If I look at the value after the second appendChild() it is 'undefined'.
>
> I can't tell from the spec if this is a bug or not. Do we know?
>
> jjb

HTH
--
Simon Pieters
Opera Software

Reply | Threaded
Open this post in threaded view
|

Re: Moving an iframe in the DOM

John J Barton
On Fri, Mar 16, 2012 at 1:45 AM, Simon Pieters <[hidden email]> wrote:

> The spec doesn't say to remove properties of the window when moving an
> iframe, so that would be a bug.

Thanks, Simon and TJ.

http://code.google.com/p/chromium/issues/detail?id=118605

Both Chrome 19 and Firefox 10 fail.

jjb

Reply | Threaded
Open this post in threaded view
|

Re: Moving an iframe in the DOM

Ian Hickson
In reply to this post by John J Barton
On Thu, 15 Mar 2012, John J Barton wrote:

>
> The HTML5 spec has:
>
> "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."
>
> To me this statement is ambiguous, since we don't know what 'not ...
> discarded' or "survive' means.

I have removed it. It was non-normative anyway.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'