What kind of new 'session' is created on manual navigation?

[jakearchibald]

Some APIs and behaviours span across multiple session entries. But, if the page is navigated to a new entry by a means out of the current page's control (user enters something into the URL bar, selects a bookmark etc etc), which of these behaviours should continue across into the new page?

I'm going to refer to that type of navigation as "manual".

WindowProxy window references

1. PageA uses window.open to open PageB in a new session.
2. PageB's session is manually navigated to PageC.

Does PageA hold a reference to PageC?

Chrome: No if PageC is on a different origin to PageB, otherwise yes (unless PageC is cross origin isolated via COOP/COEP).
Firefox: Yes, unless PageC is cross origin isolated via COOP/COEP
Safari: Yes

Ideal behaviour: This was discussed in #5767 (comment), and consensus was that PageA should not hold a reference to PageC in the cross-origin case, and this should be achieved by creating a new BCG for PageC. Although, it isn't yet clear what should happen to the reference PageA has, or what should happen if PageC's session is navigated back to PageB. We didn't discuss the same-origin case.

history.back and history.length

1. PageA's session is manually navigated to PageB.

Can PageB navigate its session back to PageA using history.back? Is history.length greater than 1?

All browsers: Yes.

Ideal behaviour: ???

It feels like a minor security and privacy benefit to treat PageB as part of a new sub-session, that cannot observe or control history entries that came before it. Whether this differs if PageA and PageB are same-origin probably depends on what we do for the previous example.

Chrome already blocks history.back() in some cases, eg when it's called from a sandboxed iframe and the navigation would happen outside the iframe. I guess even a navigation within the sandboxed iframe impacts history.state in the parent, but we already know the history API is bad.

sessionStorage

1. PageA has some session state.
2. PageA's session is manually navigated to PageB.
3. (if necessary) Use location.href to navigate back to PageA's origin.

Can the resulting page access the session state set in PageA?

All browsers: Yes.

Ideal behaviour: ???

It feels like the answer here should be the same as it is for history.back.

Related: Session storage and changing browsing contexts.

cc @annevk @domenic since we've already been talking about this stuff
cc @mikewest anyone from security interested in weighing in here?

[mikewest]

Poking folks who know things, and who might be interested in weighing in.

[asakusuma]

Another similar scenario is "right click link, open new tab." For same-origin scenarios, it would be helpful for the origin and destination page to have references to each others WindowProxy objects. Consider a search page, with a bunch of results. Users will often scroll through and right click, new tab all the results that look interesting. From a UX perspective, all of the tabs are part of the same activity, a user searching, and it's helpful to be able to share state. Right now, I believe the best to handle this is to use query params with some identifier as lookup key in persistent storage. But nobody likes query params in their urls.

[jakearchibald]

@asakusuma I guess a service worker could create that association. Also, we've thrown around the idea of having some sort of clients API outside of service workers.

[tabatkins]

Purely from a personal perspective, I feel strongly that manual navigation should create an entirely new session. Typing into the URL bar should be semantically identical to closing the tab, opening a new tab, and then typing into the URL bar. Anything less than that is at least a privacy leak, and possibly a security leak, imo.

(At least when the new page is cross-origin. I don't have strong opinions on same-origin.)

[ArthurSonzogni]

Yes, I believe every "manual" navigation (Bookmarks, address bar, ...) should start a new Browsing Context Group. WindowProxy window reference shouldn't cross two Browsing Context Group, they should be closed. It would be lovely if the history seen from the new document and the SessionStorage could start from scratch.

WindowProxy window references

I filled several security issues against Chrome and Firefox in the past. They contains many useful informations that you can check out:

• https://crbug.com/1044951
• https://bugzilla.mozilla.org/show_bug.cgi?id=1611183 and https://crbug.com/1044948

In Chrome (and I believe in Firefox too), we severe the WindowProxy relationship whenever we enter a new Browsing Context Group. I do believe we should continue to this way. That's even part of the specification for COOP+COEP.

In Chrome, this happens for:

• Various security reasons (accessing an internal page, accessing the web store, some error page, ...)
• When crossing different COOP+COEP contexts.
• cross-origin navigation with no related previously related Browsing Context:
  ProactivelySwapBrowsingContextGroup
• same-origin navigation with no previously related Browsing Context, when it helps with the BackForwardCache.
• ...

More informations in RenderFrameHostManager::ShouldSwapBrowsingInstancesForNavigation(...)

I do believe we would like to always swap Browsing Context Group for "manual" navigation. This is tracked in https://crbug.com/1044951 and I believe +@carlscabgro was interested implemented this.

The main issue: If users navigate back, we won't be able to restore the WindowProxy correctly. Once it's broken, it's broken. That's why we sometimes require having no related Browsing Context before swapping Browsing Context Group. I do believe this is not a huge problem, compared to what we gain from a security perspective. COOP+COEP is a precedent into the specification about not restoring WindowProxy. So I believe this is now easier to go further into this direction.

history.back and history.length

Yes, this would be better to start them from scratch when entering a new Browsing Context Group. The new document shouldn't be able to history.back() across them. However the user should still be able to navigate back across several Browsing Context Group.

[jakearchibald]

@ArthurSonzogni

The main issue: If users navigate back, we won't be able to restore the WindowProxy correctly. Once it's broken, it's broken.

Yeah, I'm pretty sad about that. Some of that was discussed in #5767 (comment). I'd prefer it if 'back' worked here, but it's not a hill I want to die on.

Yes, this would be better to start them (history and session storage) from scratch when entering a new Browsing Context Group.

That was my original thinking, but I think it conflates two things.

1. User is on PageA
2. User clicks link which takes them to PageB, which is cross-origin isolated
3. User clicks link which takes them to PageC, which is on the same origin as PageA and is not cross-origin isolated

In this case all three pages exist in their own browsing context group (yeah?), but since all navigation was controlled by web content, I'd consider it to be part of the same browsing session. PageC would have access to the same sessions storage as PageA, and history.back() would work for both PageB and PageC.

In terms of modeling this, a browsing context group is part of a session, but multiple browsing context groups may exist within the same session. Does that make sense?

[annevk]

One thing I'd like to see clarified in this discussion is whether "manual" is "all manual" or "cross-origin manual". If a user manipulates a path or some such they might not expect to lose session history. (Otherwise I'm mostly aligned with Jake I think, except for restoring WindowProxy. Popups are the worst. 😊)

[jakearchibald]

Proposal: When the user manually navigates from PageA to PageB, which have different origins:

• WindowProxys pointing to PageA's window will not point to PageB (already agreed)
• PageB will have new session storage.
• In PageB history.length will be 1, and history.back() will be a no-op.
• The browser back button will still navigate back to PageA.
• In PageA history.length will not count PageB's history entry. history.forward() will be a no-op.
• The browser forward button will still navigate to PageB.

When the user manually navigates from PageA to PageB, which are in the same origin, the behaviour is the same as clicking a link to PageB in terms of the above behaviours. This preserves the 'hackability' of URLs as a form of navigation.

Modelling the above:

A set of contiguous entries in joint session history form a 'session'. There may be multiple sessions within joint session history, but they are always contiguous.

Session storage is associated with a session. If the user navigates into a new session, they get a new session storage.

history.back() and history.forward() are no-ops if they would navigate a navigable into a new session. history.length is the number of history entries in that session. The browser's history controls (back/forward buttons etc) may traverse to history entries with a different session.

Clicking a link in a page creates a history entry in the same session, although it may exist in a different browsing context group due to cross origin isolation etc.

Manual navigations to same-origin URLs behave the same as clicking a link in a page.

@ArthurSonzogni @annevk does that work? Any idea who should weigh in from WebKit?

Manual navigations to cross-origin URLs create a history entry with a different browsing context group and new session.

[smaug----]

If PageA has been originally opened using window.open() from Page0, what happens to the reference in Page0?
So basically the same question which is mentioned in the initial comment.

[jakearchibald]

@smaug---- I think that depends on whether navigating back to PageA should restore its connection with Page0. There's some discussion of that in #5767 (comment), but I don't think we need to decide that before getting consensus on the 'manual navigation' stuff.

If we decide that manual navigation creates a new 'session', and therefore new browsing context group, then the window proxy behaviour will be the same as an in-page navigation to a cross-origin isolated page.

[tabatkins]

When the user manually navigates from PageA to PageB, which are in the same origin, the behaviour is the same as clicking a link to PageB in terms of the above behaviours. This preserves the 'hackability' of URLs as a form of navigation.

Yes, upon further thought I realized I did have strong opinions about same-origin, and wanted it to do exactly this, so that I could navigate myself around a site by hacking the url.

[JakobJingleheimer]

I think manual navigation is irrelevant:

• history should be isolated per tab and per origin (new tab at same origin should have a new history)
• session-related things (ex sessionStorage) should be per origin per window

If a user is on PageA and manually updates the URL in the address bar but maintains the same origin, history should persist (with the new entry added, length increased by 1, etc).

[jakearchibald]

@JakobJingleheimer compared to my proposal, you're asking for session history to limited further (in a way that's likely incompatible with the current web), and session storage to be limited less. Can you explain how this asymmetry makes sense to the user and how it benefits them?

[JakobJingleheimer]

With the web moving more and more toward application-like use, a window is essentially a container for an application and a tab is a workspace. Different views of the app need access to common resources, like the app's session (eg sessionStorage).

A user would expect limited isolation within the workspace: "undo" in workspace 1 should not spill over into workspace 2.

Anything within the same origin seems fair game to that origin—it already knows what happen before, so why make it more difficult?

I think something like a hard refresh (instead of a soft refresh) should reset history (as it resets everything else), but manually updating the URL seems just another (perhaps, advanced) way of interacting with the current context. If a user happens to know the route they need is /foo/bar and it's easier to update the address bar, that seems equivalent to clicking a link to /foo/bar, no?