Update session history

[noamr]

Since we're making the successor BC the current one, we need to keep the previous BC's session history, and append/replace the successor's entry. There should be only one entry due to https://wicg.github.io/nav-speculation/prerendering.html#always-replacement, and we should take history handling into account.

[domenic]

Thanks for tackling this! Unfortunately I think this is a bit more involved, and something like this doesn't quite work due to the shaky foundations we're building on.

Consider the case of activating prerenderingBC in place of predecessorBC.

Since you have just copied (or, actually, made a reference to) the old session history entries, what will happen when the user presses back is that they will traverse the history of prerenderingBC to a session history entry whose various internal values (e.g. document, browsing context name, ...) reference predecessorBC.

This is compounded by how traverse the history is not well-specified and seems like it will get confused. E.g. step 1.4 says "Navigate the browsing context". I guess it's relatively clear in context which browsing context we're talking about there, since each session history is associated to a single browsing context. But with the changes here, the session history is now associated to two browsing contexts, so it's no longer clear. And even if we picked one, either answer seems kind of broken: do we traverse prerenderingBC back to a session history entry it's never been at, while predecessorBC's current entry is now "ahead" of what the user actually sees? Does the user ever revisit predecessorBC at all?

The ultimate goal here should be to model this on top of whatwg/html#6315, but that is not finished yet. I believe in that model we would keep the same traversable, and swap between browsing contexts as you traverse across the boundary. (See whatwg/html#5350 (comment).) @jakearchibald might be able to fill this in. @jakearchibald, @domfarolino and I plan to work on this in late February, hopefully getting that spec to a landable place.

However it's probably worthwhile creating something in the short term that tries as best it can to build on top of the current, not-very-good session history infrastructure. For that I can think of a few possibilities:

• State the eventual goal and normative requirements, just not in algorithms. E.g.: the successor browsing context joins the browsing session of its predecessor. Traversing across the boundary (e.g. with history.back() or history.go(-2) will traverse the "joint session history of the whole browsing session", which is not a defined concept, but should be somewhat clear how it would work. In particular it will cause the user to end up looking at the predecessor BC. From which they can then go forward to the successor BC. This will all be formalized when Navigation and session history rewrite whatwg/html#6315 lands, but for now, we try to write things down in enough detail that it's clear to browser engineers how it should work, and any behavior we capture in web platform tests is understandable from the spec.

• Hack 1: copy relevant stuff into successor BC, and discard the predecessor BC. This is kind of the direction you've gone here, but you've only done the session history; I think you probably need to copy some more stuff. (E.g. update any WindowProxy <-> browsing context correspondences; make sure a document's browsing context pointer is good; maybe copy stuff like virtual browsing context group ID, initial URL, and opener URL at creation; figure out the relationship to browsing context groups...)

• Hack 2: copy relevant stuff into predecessor BC, and discard successor BC. This seems a bit easier than hack 1, although perhaps it's just a matter of copying the same stuff, with hack 1 requiring a loop and hack 2 being a single time.

I think the first route is my preference...

[noamr]

Thanks for tackling this! Unfortunately I think this is a bit more involved, and something like this doesn't quite work due to the shaky foundations we're building on.

Consider the case of activating prerenderingBC in place of predecessorBC.

Since you have just copied (or, actually, made a reference to) the old session history entries, what will happen when the user presses back is that they will traverse the history of prerenderingBC to a session history entry whose various internal values (e.g. document, browsing context name, ...) reference predecessorBC.

This is compounded by how traverse the history is not well-specified and seems like it will get confused. E.g. step 1.4 says "Navigate the browsing context". I guess it's relatively clear in context which browsing context we're talking about there, since each session history is associated to a single browsing context. But with the changes here, the session history is now associated to two browsing contexts, so it's no longer clear. And even if we picked one, either answer seems kind of broken: do we traverse prerenderingBC back to a session history entry it's never been at, while predecessorBC's current entry is now "ahead" of what the user actually sees? Does the user ever revisit predecessorBC at all?

The ultimate goal here should be to model this on top of whatwg/html#6315, but that is not finished yet. I believe in that model we would keep the same traversable, and swap between browsing contexts as you traverse across the boundary. (See whatwg/html#5350 (comment).) @jakearchibald might be able to fill this in. @jakearchibald, @domfarolino and I plan to work on this in late February, hopefully getting that spec to a landable place.

However it's probably worthwhile creating something in the short term that tries as best it can to build on top of the current, not-very-good session history infrastructure. For that I can think of a few possibilities:

• State the eventual goal and normative requirements, just not in algorithms. E.g.: the successor browsing context joins the browsing session of its predecessor. Traversing across the boundary (e.g. with history.back() or history.go(-2) will traverse the "joint session history of the whole browsing session", which is not a defined concept, but should be somewhat clear how it would work. In particular it will cause the user to end up looking at the predecessor BC. From which they can then go forward to the successor BC. This will all be formalized when whatwg/html#6315 lands, but for now, we try to write things down in enough detail that it's clear to browser engineers how it should work, and any behavior we capture in web platform tests is understandable from the spec.
• Hack 1: copy relevant stuff into successor BC, and discard the predecessor BC. This is kind of the direction you've gone here, but you've only done the session history; I think you probably need to copy some more stuff. (E.g. update any WindowProxy <-> browsing context correspondences; make sure a document's browsing context pointer is good; maybe copy stuff like virtual browsing context group ID, initial URL, and opener URL at creation; figure out the relationship to browsing context groups...)
• Hack 2: copy relevant stuff into predecessor BC, and discard successor BC. This seems a bit easier than hack 1, although perhaps it's just a matter of copying the same stuff, with hack 1 requiring a loop and hack 2 being a single time.

I think the first route is my preference...

OK, I must say I'm still not following the thought process of "navigable" and "traversable". I'd let this mature a bit first, this issue is not a blocker currently.