An iframe whose history can be transferred across parent navigations

[jakearchibald]

Jotting down an idea that's been bouncing around my head:

The problem

There are cases where you have an embedded piece of content that ideally should not lose state across navigations, such as:

• A customer service chat widget.
• A media player.

In the case of a chat widget, you can reload state from the server and continue where you left off – it's just not as fast as it could be.

With the media player, you're always going to get a break in playback.

The current solution is to turn your site into an SPA, to avoid cross-document navigations. This is a big undertaking, and usually leads to a loss of performance in other areas.

A solution?

A special type of iframe that:

• Can move around the DOM without reloading (solving some of https://github.com/whatwg/html/issues/5484).
• Is a nested traversable (as in, it manages its own session history, and doesn't take part in global back/forward button history).
• Can never have its content synchronously accessed.
• Can be 'reparented' across navigations.

As in, if you're navigating from A to B (same-origin and same-isolation), and both contain <magiciframe name="foo" src="page">, rather than reload page from scratch, B will adopt the traversable from A. If B doesn't contain a home for the iframe, it's either bfcached with A or unloaded.

This is building on iframe history reparenting, which browsers already do.

[jakearchibald]

There's some cross-over with portals here, although I think portals only go from embedded to top-level, and vice versa, rather than embedded to embedded.

[robertknight]

Can move around the DOM without reloading (solving some of https://github.com/whatwg/html/issues/5484).

How are the technical issues raised by WebKit devs in eg. https://github.com/whatwg/html/issues/5484 solved here? By guaranteeing that synchronous communication with other frames will never happen?

I work on a widget that gets loaded into existing third-party web pages and we sometimes run into the issue that some other script on the page will move DOM elements around and inadvertently reload our iframe and sever its MessageChannel-based connections to the main frame. So a way to prevent that reload happening would be great.

[jakearchibald]

The details of the potential security issues for webkit are a little light on detail, so I'm not sure.

[Boldewyn]

You know, we wouldn’t have these problems, if someone had actually fixed URLs for <frameset>s in the late 90s (and, admittedly, the tons of other issues with <frameset>, but I digress...). 😁

[jakearchibald]

@Boldewyn the same thought crossed my mind. However, this proposal would also allow the iframe to be popped out to a new window.

[noamr]

Love this! I think it addresses one of the main reasons people have to resort to SPAs (aside from the elusive "DX"). Losing state when navigating across documents, whether it be iframe state or form state, makes MPAs a lot less attractive.

I wonder if it can be an iframe attribute rather than a new type of element?

[jakearchibald]

I wonder if it can be an iframe attribute rather than a new type of element?

I think this will come down to how it works with other iframe attributes. Eg, does it make sense with a srcdoc? Maybe it does.

[noamr]

I wonder if it can be an iframe attribute rather than a new type of element?

I think this will come down to how it works with other iframe attributes. Eg, does it make sense with a srcdoc? Maybe it does.

SG. Hope we find a way to pick this up.