[whatwg/storage] Session storage and changing browsing contexts (#119)

I'm trying to figure out how session storage should behave in a few similar cases.

I think the possible options for each of these are:

a) The new page has fresh, empty session storage
b) The new page has the same session storage
c) The new page has a clone of session storage

…where b is generally what happens while navigating around in the same tab, and c happens when opening a popup.

References to "isolated" here mean `Cross-Origin-Opener-Policy: same-origin`.

**1. User navigates from non-isolated pageA to isolated pageB in the same tab.** My gut feeling is that "b" is ok here. Only visible data would be able to pass from pageA to pageB. This may be the first time a single unit of session storage has been shared between a (process, origin) pair, although it's pretty common with localstorage.

**2. pageA performs a `<link rel="prerender">` of pageB. User navigates from pageA to pageB in the same tab and the prerender is used.** A prerender will exist in a new browsing context, so this is similar to the previous case, and imo have the same result, "b". The difference is, in the same-origin case, it's more likely that each process will be accessing session storage at the same time.

**3. User navigates from pageA to pageB by changing the URL in the URL bar.** This case feels different to me. Since the navigation hasn't been caused by web content within the session, "a" feels more appropriate. However, if the user clicks back, the previous session storage should be present.

**4. Non-isolated pageA opens a popup to isolated pageB.** Again, it seems ok to continue with the current behaviour, which is "c". That seems to be what Chrome does now.

@annevk @rakina does the above make sense?

If so, I think I'll change what I'm currently calling "browsing session" to "top level navigable" (making a special kind of navigable), since it's supposed to represent a window/tab. Then I'll give browsing contexts a session bucket/ID. Multiple browsing contexts can share the same session bucket/ID, and a top level navigable may contain history entries that have browsing sessions with different session bucket/IDs.

This would also allow us to add logic that prevents `history.back()` traversing to a history entry with a different session than the current entry, although the browser back button would not have this restriction.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/119