Reparenting iframes without reloading

[josepharhar]

I have heard several requests for the ability to reparent iframes without reloading, including:

• React maintainers
• This stackoverflow post
• Chromium engineers working on portals

Has this been brought up as a spec issue before? I imagine someone must have thought about this before...

Would it make sense to add a method to iframes to reparent them to another element without reloading?

Another potential use case I've heard from React is to reparent elements other than iframes without losing state. An example of this would be to reparent an input element without losing focus and selection. In this case, perhaps we could have a reparenting method for any element?

cc @mfreed7 @tkent-google @sebmarkbage

[josepharhar]

Some more clarification: right now the use case only involves moving iframes or other elements within the same document without ever actually detaching them.

[mfreed7]

@jeremyroman

[annevk]

Node trees don't offer move as a primitive operation.

[tkent-google]

Some people implemented this behavior in WebKit, found several critical issues, and removed it.
This issue contains some pointers.

[josepharhar]

Based on this patch which removed magic iframes, it sounds like they were for moving iframes between documents, which sounds more vulnerability prone than moving iframes inside of one document.

Ryosuke's comment at the end of the issue makes it sound like there are also security vulnerabilities with moving iframes inside the same document, but I wonder if the security vulnerabilities they encountered were really for the same document cases...

[rniwa]

Based on this patch which removed magic iframes, it sounds like they were for moving iframes between documents, which sounds more vulnerability prone than moving iframes inside of one document.

Ryosuke's comment at the end of the issue makes it sound like there are also security vulnerabilities with moving iframes inside the same document, but I wonder if the security vulnerabilities they encountered were really for the same document cases...

The most of security issues were agnostic to whether an iframe was moved across a document or not. The main issue is the document inside a (temporarily) disconnected iframe being considered alive.

[josepharhar]

Thanks for the feedback Ryosuke!

Do you think that it would be possible to move the iframe atomically and therefore never have a document in a disconnected frame?

[rniwa]

Do you think that it would be possible to move the iframe atomically and therefore never have a document in a disconnected frame?

That was the idea. But how does one move a node from one place to another? Since a node can't have multiple parents, it needs to be disconnected at some point in some internal engine state. That's precisely what caused the problem. In particular, if there are multiple iframe that could get disconnected in order, then they can access each other in weird ways in scripts, etc... I'm not gonna go into details but I don't think this is an idea we should re-pursue anytime soon.

[sebmarkbage]

Moving between parents would be very useful but the use case for React (and similar) is to be able to move position within the same parent. Eg swapping the place of two nodes in the same parent.

[annevk]

@rniwa did you introduce a new type of mutation for node trees? It seems to me you would have to start there. We only have remove/insert at the moment.

[rniwa]

@rniwa did you introduce a new type of mutation for node trees? It seems to me you would have to start there. We only have remove/insert at the moment.

I don't recall but I don't think that really helps so long as such a replacement involves more than one node at once (e.g. subtree) because then a subtree can contain iframe which then need to be kept alive, etc...

[annevk]

I think it would help in that you can define now rules around it in terms of script execution, but it would be a pretty large undertaking and there's a lot of non-interoperable behavior around this for the current remove/insert operations that should be sorted first.