I figured we might need to solve this problem so I've been designing for it in #6315, but it's a little different to what you're proposing here.

I have:

• Navigable - A thing that can be navigated, such as a top-level page or an iframe.
• Traversable - A navigable that hold session history and manages the traversal of itself and its nested navigables.

Currently, browsers only treat the top-level as traversable, but the model will allow for traversables to be nested.

However, in this model, nested traversables would have their own session history of multiple entries, rather than have everything turned into "replace" navigations. These history entries wouldn't be traversable via the back/forward buttons, but could be traversed using history.back() and the new appHistory APIs.

Since the top-level doesn't store the session history of nested traversables, their session history wouldn't be repopulated after going back to the page (unless of course the previous page was kept alive in bfcache).

The benefit of this is you wouldn't need to remove history.back() from these contexts, since it'd only impact the session history of the nearest traversable, not the top level. Also, we wouldn't need to make it opt-in, since the behaviour would be normal, just sandboxed.

The downside is it might be more complicated to implement, but I'm not sure.

I think what @jakearchibald outlines matches what we wanted for #763 (see also the very long discussion at WICG/webcomponents#184). A good initial test for this feature might be deploying it for shadow iframes.

cc @rniwa

What is the appropriate model for how to impose this? I can think of a few options:

• Global page-wide <meta>, applies to all descendant iframes
  • Descendant iframes cannot opt out; this is imposed on them
• Document policy, applies to all descendant iframes
  • Descendant iframes need to agree to this via the Sec-Required-Document-Polic / Document-Policy dance
  • Seems not very useful as you'd have to convince all your descendants to agree
• Permissions policy for "contribute to history", which by default is allowed for all iframes
  • You can disable per-iframe using allow="nested-history 'none'"
  • You can disable it for everything on your page using the HTTP header Permissions-Policy: nested-history=()
  • You can disable it for non-same-origin iframes using the HTTP header Permissions-Policy: nested-history=(self)
  • But there's no in-markup way of disabling it for all descendant iframes which is a bit sad
• A new sandboxing behavior
  • By default sandboxed iframes do not contribute to history
  • They can be allowed to by sandbox="allow-nested-history"

Of these permissions policy seems pretty good...

Yeah, although I'm not a big fan of opt-in for third parties, I agree it fits here. (And perhaps we can switch the default over time.)

cc @clelland

Some implementation discussions among the Chrome team revealed that implementing the variant of this that @jakearchibald proposes, with independent session histories for the iframes, would be quite difficult. Also, it could be confusing for users in cases involving iframe restoration.

The proposal we're favoring now is to have this make every navigation in the iframe a "replace" navigation. This still meets the use cases I'm most concerned with, which is letting pages ensure that iframes don't add entries to the joint session history.

Does that still sound reasonable to Mozilla folks? /cc @smaug----

What happens with a nested history.back()? In scenarios where this is forced upon nested documents that still functioning could end up breaking things in unexpected ways.

I'm also still wondering if we could make this the default for shadow tree nested documents to solve the leakage problem there.

Yeah, it could indeed have that impact. I think that's OK?

I remain doubtful that it would be web-compatible to change how shadow trees work, but we'd welcome anyone running an experiment to prove us wrong.

In the case where this is a policy you force upon descendants you probably would not want any descendant to be able to navigate away from you again. It seems quite easy for a descendant to have some pushState() + back() logic that would break the top once run.

Oh, I see, because back() would still operate on the joint session history. Yeah, I agree that would be bad.

Were you thinking we would just make back() etc. a no-op in these frames?

I was wondering what you all were thinking since @jakearchibald hinted at this being a problem in #6501 (comment), but no-op would work I think.

@domenic

Also, it could be confusing for users in cases involving iframe restoration.

In what way?

I think I was making a few logic jumps there that are not, in retrospect, justified. In particular I was thinking "having to save/restore/sync for these independent session history lists would be a lot of work to spec/implement, so, we should probably just not do so and restore from the src="" attribute. Which would lead to a confusing user experience." But yes, if we went to the trouble of implementing and speccing not only independent session history lists, but also saving/restoring them, then I think there are no user experience problems.

So this is mostly a question as to whether the web developer experience gains of allowing non-replace navigations/nontrivial session history in these scenarios is worth the implementation cost. I think the Chrome history engineers' position is that it is not worth it, and I tend to agree.

So this is mostly a question as to whether the web developer experience gains of allowing non-replace navigations/nontrivial session history in these scenarios is worth the implementation cost. I think the Chrome history engineers' position is that it is not worth it, and I tend to agree.

Expanding on the Chrome implementation position, I think what's really hard to implement is actually full separation of top-level and iframe session history in general. So even if we had replacement-only session history model in iframes, I think what would be really challenging is (a) the back button restoration stuff mentioned earlier, (b) Divorcing the history entirely (i.e., not sharing history.length, having history.back() in an iframe not influence the top-level page). I think that's the tricky part. That is, the implementation complexity is agnostic to the triviality of the session history model in the iframe, but is related to the completeness of the separation in general. I'd like @csreis to correct me though if I am wrong.

So even if we had replacement-only session history model in iframes, I think what would be really challenging is (a) the back button restoration stuff mentioned earlier, (b) Divorcing the history entirely (i.e., not sharing history.length, having history.back() in an iframe not influence the top-level page).

Hmm, my impression was different. (a) restoration gets pretty easy if we only have to serialize "current URL" for the iframe, and not an entire history list? Maybe? (b) history.length never changes due to replacement, only due to push. And we can just add a check (e.g. in the renderer process) to bail out for history.back(), etc. in these iframes.

history.length never changes due to replacement, only due to push

But it is still shared. If A.com embeds B.com and C.com where both B and C are sibling iframes, and C.com navigates a million times, I think all of these are observable by A.com and B.com via history.length.

Maybe this is too implementation-specific or "deep" but the question seems to be which one do we want:

• Iframes with a fully separated history from the top-level page, and their history model just happens to be replace-only for simplicity. history.length always naturally returns 1
• Normal joint session history between the top-level page and the iframe, but just patch all of the ways that the iframe could interact with the joint session history that are observable to the top-level page and vice-versa (i.e., replacement-only, manually patching history.length, more?)

The distinction between the two might be overly-pedantic from a spec perspective; if that's the case then sorry.

Hmm, my impression was different. (a) restoration gets pretty easy if we only have to serialize "current URL" for the iframe, and not an entire history list? Maybe?

That's quite possible! I'm not totally sure so I delegate to Charlie. From an impl POV it does seem like if we don't actually require fully separated iframe history but still have it operate on the same underlying objects (just in a replacement-only manner and with manually patched i.e., history.length), then yeah we'd get today's iframe restoration logic for free I think. Anyways if this comment is getting us off-track, my apologies.

But it is still shared. If A.com embeds B.com and C.com where both B and C are sibling iframes, and C.com navigates a million times, I think all of these are observable by A.com and B.com via history.length.

What I was getting at was if the million C.com navigations are with replacement, then history.length will not change.

But I agree it provides a communications channel. E.g. if B is in replace-only mode and C is not, then B and C can communicate by B observing history.length and C modifying it.

We could manually patch this out by making history.length return 1 in such replace-only iframes. Probably that's a good idea anyway since we're saying history.back() will no-op; it seems like those two should stay in sync, generally.

If we do such patching, then I hope the two are equivalent. But I agree they're conceptually different, and there might be things we miss patching which could make them diverge :-/.

Yeah, that is the only thing I am worried about, basically a slightly incomplete audit and therefore incomplete manual patches.

Side-question:

Yeah, although I'm not a big fan of opt-in for third parties, I agree it fits here. (And perhaps we can switch the default over time.)

Do we think that we could ever actually make this the default behavior without requiring all content to opt-in to being framed? Right now content can opt-out of being framed and we're discussing the possibility of making all framed content have this replacement-only model in the future. This is a big pretty big behavior difference between a given site operating in a top-level context and the same site operating in a framed context, so I feel like this would just require turning the opt-in for this new replacement-only model into an opt-in for "You're being placed in an iframe".

Hmm, my impression was different. (a) restoration gets pretty easy if we only have to serialize "current URL" for the iframe, and not an entire history list? Maybe?

That's quite possible! I'm not totally sure so I delegate to Charlie. From an impl POV it does seem like if we don't actually require fully separated iframe history but still have it operate on the same underlying objects (just in a replacement-only manner and with manually patched i.e., history.length), then yeah we'd get today's iframe restoration logic for free I think. Anyways if this comment is getting us off-track, my apologies.

To clarify, it's impractical in Chrome to restore a nested joint session history (e.g., if "nested traversables would have their own session history of multiple entries"), even if that nested history is limited to a single item. In the single item case, we would still need to store more than just the URL: also scroll position, form state, and many other things that get serialized.

However, I agree with @domfarolino that the replace-only + manual-patch suggestion seems to avoid the need for a nested joint session history. If an iframe in this mode is limited to a single session history item and can't otherwise affect the top-level joint session history, then it seems reasonable to store it as a single session history item within the top-level joint session history. That does seem like it would make restoration possible.

Surely this should be a property of a frame, and not of a specific document / navigation? At least that's what we were discussing for the shadow DOM.

Yep, this would be a property of the iframe (browsing context); that's how permissions policy works.

[Catching up]
Using permissions policy for this seems reasonable, with a default allowlist of *, as long as we're not considering the initial option of simply removing back() and friends from the history object. I suspect that doing that would require explicit opt-in from the frame.

Breaking back() gets close to that point, but it's arguably more acceptable to make it a no-op than to cause it to throw.

Having opened a related issue here: #8773, I wanted to contribute some thoughts here re iframe's maintaining their own history.

I side most closely with @jakearchibald's proposed spec.

Firstly, I think it's essential that iframes have their own maintained history, and as far as I understand, using replaceState for every navigation within iframes would make it impossible for iframes to traverse their own history. Isolating the history of iframes so they don't pollute the history of the parent window would be a great and logical next step in the evolution of iframes. However, if in doing so, iframes lose the ability to control their own bwd/fwd navigation, I think we create an even larger issue and one that might be harder to come back from.

I think its imperative that iframes can manage their own history, and that the history for an iframe can be traversed fwd/bwd from the parent frame, at least so that the parent frame can present backward/forward/refresh navigation options.

I don't think we need to worry about restoring nested joint session histories, only the top-level. As for nested iframes-in-iframes, I think it's perfectly suitable for a nested iframe-in-iframe to also self maintain its own history, and how that works would be dictated by the setting of those nested iframes allow attribute values.

For example:

Top-level window (A) ◄┄┄┄┄┐ ◄┄┄╳┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┐
 │                        ┆                             ┆
 ├── iframe:not([allow]) (B1) ◄┐                        ┆
 │    │                        ┆                        ┆
 │    └── iframe:not([allow]) (C) ◄┄┄╳┄┄┄┄┄┄┄┄┄┄┄┐      ┆
 │         │                                     ┆      ┆
 │         └── iframe[allow="isolated-history"] (D) ◄┄┐ ┆
 │              │                        ┌┄┄┄┄┄┄┄┄┄┄┄┄┘ ┆
 │              └── iframe:not([allow]) (E)             ┆
 │                                                      ┆
 └── iframe[allow="isolated-history"] (B2) ┄┄┄┄┄┄┄┄┄┄┄┄┄┘

In the above example, without using allow="isolated-history", an iframe's history entries will be added to its parent's frames, and its parent's parent, and so on until a frame is reached which isolates the history.

With this in mind…

• A history is the top-level history
• B1 history will bubble history entries up to A since it does not use allow="isolated-history"
• C history will bubble history entries up to A and B1 since neither it nor B1 use allow="isolated-history"
• D history will act a new top-level-like context because it isolates its history using allow="isolated-history", so any new history entries from D will not bubble up
• E history will bubble history entries up to D since it does not use allow="isolated-history"
• B2 (also a direct child of A and sibling of B1) history will act a new top-level-like context because it isolates its history using allow="isolated-history", so any new history entries from B2 will not bubble up

Note, rather than allow'ing history to bubble up, we allow the history to be isolated so as not to cause any breaking changes on the web, in the heart of "don't break the web".

isolate-history seems clear enough to me, though something else like nested-history or suppress-history could work as well.