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.

[jakearchibald]

Rather than inventing a new kind of tree mutation, it feels like the simplest solution for developers would be to keep the iframe alive for a microtask after disconnection (although maybe need to think more about mutation events, as they already use microtasks).

I realise this doesn't make implementation easier.

[annevk]

How would that work specification-wise? Please note https://github.com/whatwg/dom/issues/808 and ideally everything linked from there to get an idea about the complexity with regards to script execution that we have with insert and remove today. (Mutation events also fire synchronously for insert/remove and are also not specified yet and indeed also cause problems here.)

[jakearchibald]

I figured it'd be something like:

An iframe has a pending discard flag which is unset.

When an iframe element is removed from a document:

1. If the iframe's pending discard flag is set, abort these steps.
2. Set the iframe's pending discard flag.
3. Queue a microtask to run the following steps:
   1. Unset the pending discard flag.
   2. If the iframe is not connected, discard the nested browsing context & set it to null.

Although, if the iframe is inserted into another document, the current nested browsing context should also be discarded (if that was a particular source of security bugs).

[sophiebits]

For what it's worth, from a web dev perspective, there's already a way to ask for an element to be moved in a single step: just call .appendChild or .insertBefore for its new position without ever calling .removeChild. This is in fact what React already does when reordering children within a list.

[sebmarkbage]

I'd like to call out this part too:

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.

The example of iframes is one particularly complicated case but it's one of several examples of state being lost.

Text selection and focus within an <input> when that input moves position within the same parent is another case.

CSS transitions playing in a subtree will be reset if any parent is removed and appended.

These are much more common and problematic than iframes.

In this case, perhaps we could have a reparenting method for any element?

It might be worth while listing out all these cases, because I could very well imagine that it's not web compatible to change this behavior for all of them using appendChild only. That might motivate why a new API for moves is needed.

This is a big deal in diffing based solutions (this include virtual DOMs like React and template based solutions based on diffing rather than change tracking). The reason it is such a big deal is that there's nothing that says which node to move. If you swap two nodes and diff them, there's nothing in the API to imply which one should be moved. The algorithm just picks one to move. Depending on the algorithm tradeoffs you could also end up moving four other nodes to move one since it's not worth computing the longest common subsequence.

Any browser built-in diffing based approach will also need to consider this problem.

In an imperative manual API you might have some intuition about which is safer and less disturbing to move. As such this was much less of a problem for the first decades of the web. However, even then there are cases where you just have to live with the worse experience.

In React we have some code to work around cases such as restoring selection and focus which adds to the code size of React, but we leave some unsolved.

[annevk]

@sophiebits unfortunately that's not an atomic move and will do a remove and then an insert (with all the associated script running bits).

@sebmarkbage an exhaustive list of problematic moving scenarios would help a lot.

[smaug----]

An iframe has a pending discard flag

And what happens when JS runs in the iframe while the iframe isn't really connected. How does window.parent in the iframe's window work, what should history.go() do, or location.href = "newurl"? How should window.frames behave in the parent window? ...

[emilio]

Somewhat limited, but for what is worth, you can sorta get that effect with shadow DOM and slotting, it seems to work in all browsers:

<!doctype html>
<button>Toggle</button>
<div id="host">
  <iframe id="frame" src="https://wikipedia.org" slot="a" style="border: 0"></iframe>
</div>
<script>
  document.getElementById("host").attachShadow({ mode: "open" }).innerHTML = `
    <style>
      div { height: 150px; background: blue; }
      #b { background: purple }
    </style>
    <div id="a">
      <slot name="a"></slot>
    </div>
    <div id="b">
      <slot name="b"></slot>
    </div>
  `;
  document.querySelector("button").addEventListener("click", function() {
    let frame = document.getElementById("frame");
    frame.slot = frame.slot == "a" ? "b" : "a";
  })
</script>

[jakearchibald]

@smaug----

An iframe has a pending discard flag

And what happens when JS runs in the iframe while the iframe isn't really connected. How does window.parent in the iframe's window work

I looked at .parent yesterday, and it seems like that uses the owner document, so it'd still work, as in it'd return the same parent as if it were connected, which seems reasonable.

what should history.go() do, or location.href = "newurl"?

I think this should behave the same as if it were connected, but I'm sure there are tricky details.

How should window.frames behave in the parent window?

That one's less clear to me.

(I didn't mean to give the impression that this would be easy, btw)

[josepharhar]

Somewhat limited, but for what is worth, you can sorta get that effect with shadow DOM and slotting, it seems to work in all browsers:

Thanks for the workaround @emilio, I didn't see that get suggested in the stackoverflow post or anywhere else!

Rather than inventing a new kind of tree mutation, it feels like the simplest solution for developers would be to keep the iframe alive for a microtask after disconnection (although maybe need to think more about mutation events, as they already use microtasks).

@jakearchibald I agree this sounds like it would be awesome for developers because it would just make iframes stop reloading as is. However, @rniwa and @smaug----'s words make me feel afraid of going forward with this due to the non-atomic nature of doing it async.

It might be worth while listing out all these cases, because I could very well imagine that it's not web compatible to change this behavior for all of them using appendChild only.

@sebmarkbage I totally agree, I think the best step for us to do right now is collect information on all the different cases where we are losing state due to reparenting, and how common/painful each one is.

Does anyone have any thoughts on where it would be best for me to start compiling this list? Maybe a github gist or a google doc? And does anyone have any other cases to add or links to anything that would help assess how common/painful each case is?

[annevk]

I think we need two things to make progress here:

1. Getting https://github.com/whatwg/dom/issues/808 resolved somehow so it's more clearly understood what the side effects of insertion/removal are (which would allow us to be explicit about not triggering them for move).
2. Gathering use cases for move that cannot be addressed with insertion/removal. It doesn't really matter where this is done, but the outcome needs to be presented in a whatwg/dom issue as the DOM Standard would have to add this primitive. Note that adding that will require some design work as it also impacts mutation observers and such. We'd probably also have to check all the elements that have insertion/removal hooks of some kind and ensure they cannot end up in a broken state due to solely being moved. (Elements with such steps might also be a good source for use cases.)

[josepharhar]

@annevk Thanks for suggesting this path forward!

I put the problematic use cases @sebmarkbage listed here: https://github.com/josepharhar/reparenting-loses-state

@sebmarkbage are there any other related problematic use cases you know of? Are there any react issues you could point us to which show interest in any of these use cases?

[marvinhagemeister]

Happy to see that this is getting traction again!

Just wanted to re-iterate the weight of the scenarios @sebmarkbage shared. The main issue we run into with working on Preact are the same. Loosing transition state or input state (focus/cursor position/text selection) are easily at the top of the most frequent issues we have with working with the DOM.

So far we haven't found more issues than those already mentioned here.

[dead-claudia]

Related: https://github.com/whatwg/dom/issues/880 and https://github.com/w3c/csswg-drafts/issues/5334

[josepharhar]

By using the new animations api, it is possible to save and restore the state of an animation:

const savedOffset = element.getAnimations()[0].currentTime;
// reparent...
element.getAnimations()[0].currentTime = savedOffset;

I documented this with the other problematic use cases and workarounds in https://github.com/josepharhar/reparenting-loses-state I'm not sure how easy it would be for vdom frameworks to use this though - checking and restoring the animation state of every element in a tree when you reparent sounds like it could take a long time compared to restoring focus and selection where there should only be one focused element and one selection in the entire document.

It still sounds like adding a new api to atomically move node trees without clobbering state would be the best solution.

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.

@sebmarkbage After rereading this thread yet again, I realized this could be a very helpful constraint. Does simply reordering nodes within the same parent without clobbering state rather than actually reparenting them solve everything for vdom frameworks? @marvinhagemeister @developit

[dead-claudia]

@josepharhar Mithril maintainer here, and it would for us. Edit: I mean specifically reordering within the same parent without clobbering state.

[rniwa]

Rather than inventing a new kind of tree mutation, it feels like the simplest solution for developers would be to keep the iframe alive for a microtask after disconnection (although maybe need to think more about mutation events, as they already use microtasks).

@jakearchibald I agree this sounds like it would be awesome for developers because it would just make iframes stop reloading as is. However, @rniwa and @smaug----'s words make me feel afraid of going forward with this due to the non-atomic nature of doing it async.

Indeed, that's just not going to help. The issue is having any frame that's even temporarily disconnected from top-level browsing context which can run any scripts at all. Given our past experience with magic iframe, we'd probably need to do a major rearchitecting of WebKit's DOM implementation if we were to implement anything remotely that exotic in the future.

[josepharhar]

I talked a bit with @sebmarkbage, and it sounds like the more narrowly scoped idea of reordering children without losing state, rather than actually reparenting children without losing state, is the use case which would help React as well.

Based @rniwa's comments it sounds like reparenting iframes in general around the dom would be quite challenging, so I'm inclined to drop this proposal of reparenting elements all around the dom without losing state and instead focus on the child reordering without losing state idea - still with the goals of iframe reloading, animations restarting, and input selection preservation.

Could I close this issue and discuss the child reordering idea in another issue? Would it be better to discuss this in whatwg/html or whatwg/dom?

[josepharhar]

Oh I just realized another option for tracking this - I could just change the name of this issue instead of opening another whatwg/html issue. @annevk what do you think?

[annevk]

Whichever way you prefer. Anything we do to address this would need changes in DOM and HTML (and probably CSS). https://github.com/whatwg/html/issues/5484#issuecomment-622826440 still seem like good next steps here.

[josepharhar]

Thanks! I made a new issue to propose a new method for reordering here: https://github.com/whatwg/dom/issues/891 I'll close this issue because I'm not interested in only the iframe case or reparenting without losing state to other parts of the DOM. If we need another HTML issue about something else I'll open another one.

[AwokeKnowing]

I ran into this issue because I wrap an iframe just before going fullscreen. didn't realize til today it was restarting it.

[AwokeKnowing]

I cannot 'pre-wrap' the iframe because it is a Tech in videojs, and the css and other things for styling the player on the page mean the player has to be the top element. I wrap it when going fullscreen because there is no concern for it's size on the page, as it's full screen. but If i pre-wrapped it, the styles of the page would have an unexpected extra layer. This is a general problem, not just my case.

The point is, wrapping something before going fullscreen, to allow scrolling in fullscreen (like YouTube) is common need for cases where you are including a 3rd party item like a video player which you don't have control over.

anyways, what are the odds this can ever get done, and is shadowdom the only known workaround (and does it work?)

[worldpeaceenginelabs]

What about using CSS? Exchanging visible to invisible in CSS (open/hide), exchanging the position of the iframe in CSS (top left, top right, bottom left, bottom right), or even give the actual "left click hold / mouseposition" to a variable that exchanges the CSS value with the actual value perpetual (click and drag element)

Maybe coding beginner bogus, but maybe not? You know better than me... Facing the same issue. I like to prevent my iframe from reloading, when i open/close/open the modal containing my iframe.

Here is my actual app i am working on: https://metaverse-dao.pages.dev/ The Iris button does open/close the Iris webapp. But it reloads every time when open/close. 😪

[Lampe2020]

I'm currently developing an OS simulation and when the focus changes I prevent the previously focused window from disappearing below later-opened windows that already are in the background by just reinserting them on focus (with document.body.appendChild(windowdiv); so they are sorted after last user interaction in the DOM.
I also have implemented some "apps" in extra HTML files (some of which need the own namespace!) that I include into the main UI using iframes - but they reload and lose all user interaction-caused content (like text in a text box) whenever I focus the window with the iframe inside.

[worldpeaceenginelabs]

How about this solution?

1. First time clicking the button to open the iframe, the button runs modal open. (like usual)

2. Then offering two buttons on the iframe: 1. close/exit 2. minimize/hide

3. if you click 1. close/exit, it runs close modal. (like usual)

4. but if you click 2. minimize/hide, you just set the iframe window to invisible with css (swap the style in runtime via variable, so it continues to run invisible in the background) At the same time, our button from step 1. gets replaced by a button that runs css:visible, instead of open modal.

5. If you click then 1. close/exit, it runs modal close, and swaps the button from step 1, back to the modal open function.

Would that work?

[Lampe2020]

@worldpeaceenginelabs That's not the problem.
My problem is that the windows in the background all have a z-index of 1 and the browser just sorts them after their order in DOM (the order in which they were added to the DOM) and I don't know how else I would order them. The problem is that, to get the window to the bottom of the DOM (so it would appear in front of other already-unfocused, later-added windows in the background) I have to reinsert it which makes the iframe lose its status.
The problem isn't the hiding/showing of the windows, the problem is the focusing/unfocusing and most importantly the order in the background (still visible) that is messed up. I can do a little video collection on https://os.lampe2020.de/demos/fokusproblem-0/ that'll show the problem clearly.

[worldpeaceenginelabs]

@Stehlampe2020 ah ok. sorry. it looks very very cool. 👍🙏

maybe the following will help you, because i am working on something that will behave like a web desktop os too. with (web)app-drawer(later js apps too), app-windows with minimize, closing etc.

actually i never thought about layer order, maybe you should overthink your ui concept? mine does open a whole page or just one window at a time. (https://metaverse-dao.pages.dev/)

i think, for my app, i will stick with the ui concept for simplicity. (the majority of stuff is happening on the globe, the pages and windows are mostly app related ui's which control the functions on the 3d globe)

What you could try, with or without switching to Svelte is the following:

i code in svelte. every page is also a component.every component is also a filename.svelte

every file contains script, html, and its own, local CSS style (per component) if you would define and later swap the css-z value in each file in run-time (style = z: variable) and fill the variable via let export variablename from your mainfile (the mainwindow, usually named app.svelte), then you could control the z indexes of all windows from your app.svelte (which doesnt reload, so you dont loose the information. and if reload, there is a way to save the state of the mainwindow(your app.svelte) somehow anyway of course)

Another way in svelte would be to use so called slots. but i think thats even more complicated with no advantage. but you should check out svelte slots for inspiration maybe.

svelte is not a language, but a typescript compiler. no svelte specific knowledge neccessary to start out of the box or just copy-paste your existing whatever framework code into it. i could help via videocall. i am from Cologne, i read you are German too. Maybe i can help you, which in turn could improve my app too.

I can just strongly suggest svelte, because my app above runs on the edge, has a p2p back-end(no servers, just relays), is a pwa and whatsnot. with not even 200 lines of code (no framework agnostic boilerplate), which where 95% copy paste stuff of cesium js(the globe itself) with some modifications. the main part (p2p core) is just around effective 15 short lines.

And my compiled code is clean, super fast, super small vanilla js(runs everywhere), which i actually cant code, but svelte does it for me. i just do typescript. also there is no dom or router, just pure logic :D (mainapp, functions, variables, modals, links, iframes)

But it wasnt about bringing you to svelte, but i know what i am doing in svelte automatically (component equals page equals component and the way i would solve your problem in svelte) is manually possible in whichever framework you are working. if you experienced, you get my point and figure it out.

I am a coding beginner by the way(in writing code), but studying, reading, understanding(!?) coding concepts and sourcecodes of different languages for almost 3 decades now. So i can be of help, but its hard for me to explain, because i often dont know the terms (which i dont care😂), so i can only explain in examples like this.

cheers

[worldpeaceenginelabs]

@Stehlampe2020 PS: After writing this, i just thought: Why not running ALL the iframes on the main-window, and just streaming their content to the pop up windows? this way there was no reload!!!

[Lampe2020]

@worldpeaceenginelabs Can you point me to a resource about streaming an iframe's content to a <div> (my windows are all <div>s)?
EDIT: I've now added a screen recording to the page linked in my last comment.

[worldpeaceenginelabs]

@Stehlampe2020 interaction order makes more sense. this is the one we all used to in windows, linux, etc... the other method looks like a glitch, because the user sees the flipping ordering of the windows. (i mean there was usaully a reason why the user left a window at its postion at the first place, but the order algo ignores that and does rude its thing)

i take a look into the streaming thing. In Svelte it would be Slots i guess. https://blog.logrocket.com/comprehensive-guide-svelte-components-slots/

It shouldn't matter if

<Card>
  <h1>Hello!</h1>
  <p>This is a box. It can contain anything.</p>
</Card>

or

<Card>
  <h1>Hello!</h1>
  <p>This is a box. It can contain anything.</p>
  <iframe></iframe>
</Card>

But this code is on your mainpage, so as long as the mainpage doesnt reload, the iframe should consist, something like this...

Maybe there is an equivalent in your coding language. Which language is that in the Video? Typescript without framework?

[worldpeaceenginelabs]

@Stehlampe2020 i really hate pop-ups, but i found this article last week (https://javascript.info/popup-windows) and thought about using !labeled! pop-ups instead. (they come with the danger not popping up because of adblock or not supported, but not supported or allowed can also happen with iframes and even js itself, so pfff) :D

then they would get managed by the general tab manager of the browser and/or window manager of the computer os. but you could define size and look of these tabs and windows, where they pop up, if with address bar or not, with menu or minimize/close or not, etc etc....

and since they are labeled you can check and call for/on them...

[worldpeaceenginelabs]

@Stehlampe2020 Maybe you could just use the svelte slot feature in your app with adding svelte via npm svelte@latestf? And then something like this: https://ashutosh.dev/svelte-slots/

Because i just remembered this:

You can use Svelte to build single, reusable components for projects of any kind, including larger applications written with Angular, React, Vue, or any other frameworks.

But even easier: If you want to go the full svelte way, start a new repo with npm vite@latest and choose svelte/TS in the prompt. (ready pre-configured, much better than npm svelte. you can start out of the box in typescript, just copy paste your code from the video into the new repo) That gets you the lightspeed fast vite compiler on top. run dev, hot reload ready in under a sec, builds in under a minute, even on larger apps. edge-ready of course. 😍👍

Tell me please, in case you found the svelte slot equivalent in whatever language/framework you code in!

[Lampe2020]

@Stehlampe2020 i really hate pop-ups, but i found this article last week (https://javascript.info/popup-windows) and thought about using !labeled! pop-ups instead. (they come with the danger not popping up because of adblock or not supported, but not supported or allowed can also happen with iframes and even js itself, so pfff) :D

then they would get managed by the general tab manager of the browser and/or window manager of the computer os. but you could define size and look of these tabs and windows, where they pop up, if with address bar or not, with menu or minimize/close or not, etc etc....

and since they are labeled you can check and call for/on them...

This wouldn't work for me as Firefox doesn't allow for hiding of the address bar (not even in popups from trusted sites) and I don't want to make real windows in the real OS but just simulated windows inside the page.

And to the thing with svelte: I want to keep my page free from any CMS or not-self-written code. I only do HTML, CSS and vanilla JavaScript and even if some code is copied from StackOverflow I have inserted it in the exact way it looks in the page source sent to the user.
That's my sites' principle, only things that I fully understand and have full control over should happen there.
I have even written my own "library" that implements a lot of little, useful functions the site may need (cookie handling, page reloading to another URL, ...).

[worldpeaceenginelabs]

@Stehlampe2020

I want to keep my page free from any CMS or not-self-written code. I only do HTML, CSS and vanilla JavaScript and even if some code is copied from StackOverflow I have inserted it in the exact way it looks in the page source sent to the user.

we doing the exact same thing. i switched to svelte, because every component is like this:

<script>
<markup>
<style>

this stackoverflow coping was important to me to. and the clean code of course.

you can go with vanilla also, but svelte will even transfer your copied typescript or whatever snippets into vanilla automatically.

plus the svelte environment from vite@latest is just devs dream.

i shit you not :D svelte is just a better compiler / environment, but no svelte specifics neccesary.

Just copy/paste your vanilla and stackoverflow stuff and see for yourself.

you will love it

[worldpeaceenginelabs]

I want to keep my page free from any CMS or not-self-written code. I only do HTML, CSS and vanilla JavaScript and even if some code is copied from StackOverflow I have inserted it in the exact way it looks in the page source sent to the user.

I tried a lot of frameworks and cms libs and services, but came to the conclusion that the JAMstack is my best new friend, since i want it clean vanilla, small, fast, edge-ready and re-usable (community friendly) which the svelte compiler/vite bundler in vite@latest comes with, right out of the box 😍😍😍 (npm build makes vanilla) 😍😍😍

so I can highly suggest it. btw: svelte(best jamstack compiler), NOT sveltekit!!! (framework)

and if I couldn't convince you of the svelte, minimum go for jamstack. https://jamstack.wtf/

both supports exactly what you are doing now, just better. ;)

[jryans]

@worldpeaceenginelabs Your last few messages don't really seem on topic for an issue in the HTML repo like this. Let's keep the discussion here focused on reparenting iframes and discuss other things somewhere else.

[worldpeaceenginelabs]

@jryans Hi :) i see, that i totally forgot the mainreason why i started mentioning svelte 😅 sorry

There is no DOM in svelte. For your reparenting iframes issue it means, no dom update neccesary. Svelte advertises itself as truly reactive and its true. Svelte apps update itself partially. (in this case updating the frame, but not reloading the content)