Leaning on bfcache and history traversal

[jakearchibald]

Portal activation and how I imagine the back button might work seems to have a lot in common with bfcache. I wonder if we can lean on it and avoid spec'ing a whole new kind of navigation.

Activating a portal

Instead of step 4 of 'activate a portal browsing context', call update the session history with the new page, with the following changes according to a "isPortalActivation" flag:

• Step 1: Unsure whether we should unload at this point (see below).
• Step 2: "If the navigation was initiated with a URL that equals the browsing context's active document's URL" needs an additional "and isPortalActivation is false" clause. This is handling fragment changes, which don't apply here.
• Step 4: "Try to scroll to the fragment for the Document." - The linked steps seem really hand-wavey, so it's probably fine to do this. For example, if the activating portal is changing viewport size as part of activation, we might want to correct scrolling.

The HTML steps here talk about a "new entry" which is really hand-waved. For portals, we should create an entry that has a fromPortal flag, which would be a new field of a session history entry.

The above steps involve traversing the history, but I don't see anything that would need to change.

Unloading

It feels like we have two options: perform the closing steps before switching the documents, or do it afterwards. In terms of closing before switching documents:

Pros:

• beforeload can present UI.
• Follows the behaviour of bf cache, so… consistency??

Cons:

• We'd probably have to respect a document's salvageability, meaning the activated portal would not be able to adopt the previous page if had beforeunload or unload listeners.

Now I've written it down, it feels better to continue to do what the spec is currently doing, and only run the close steps once the adopted portal is closed.

Traversing history

This would automatically use traverse the history by a delta:

• After steps 5: Let allowAdoption be true if the specified entry holds a Document, and one of the following is true:
  • Delta is 1, and the specified entry's fromPortal flag is set.
  • Delta is -1, and or -1, and the joint session history's fromPortal flag is set.
• Step 6.2.2: The substeps will not run if allowAdoption is true.
• After step 6.3: If allowAdoption is true, fire some kind of event that allows the new page to adopt the previous one (if the page isn't adopted, it should be closed).

Traversals that aren't 1 or -1 should just work, as the session entry's document would be promoted as if it were a bf cached page.

I haven't thought much about the event names yet.

[jakearchibald]

I'm going to close this. I think we have consensus that portals and bfcache need to interact in some way. I'll create additional issues for specific details as they come up.