Future browsing context group dependency hint

[kjmcnee]

WebKittens

@annevk

Title of the spec

Future browsing context group dependency hint

URL to the spec

https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint

URL to the spec's repository

https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

https://github.com/w3ctag/design-reviews/issues/979

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/1059

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This proposal extends the use of the "opener" rel type to same-window navigations to signal to the browser that the destination page will open a new window and the referring page expects to be able to access it. Some user agents perform browsing context group changes on navigation that aren't strictly necessary for security in order to improve performance. This results in named window reuse not being possible across a back navigation. Annotating an anchor element with "opener" will signal to the user agent that performing a browsing context group change would break a future opener relationship.

Regarding specification, this proposal would consist of a patch for the html spec. See here for details: https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint?tab=readme-ov-file#specification-changes

Note that I put @annevk as the potential reviewer given previous activity on relevant issues such as: https://github.com/whatwg/html/issues/4198 https://github.com/whatwg/html/issues/313 https://github.com/whatwg/html/issues/5350

Thanks.

[annevk]

I think solving https://github.com/whatwg/html/issues/313 first would be a good first step here. There's no need for that to be implementation-defined. It's just a specification bug that nobody has fixed as-of-yet. Once named targeting has a proper definition, it would be much easier to evaluate any proposed tweaks to it.

(That's a general pattern I would recommend when working on something with swampy underpinnings. Fix the foundation first.)

[kjmcnee]

Indeed, for this proposal to be meaningful for the spec, the named targeting needs to be scoped to BCGs. See the Specification changes section of the explainer.

However, I don't think fully solving issue 313 is needed here as there are a number of considerations beyond what's relevant to this proposal. This proposal isn't actually changing named targeting; it's changing BCG swaps on navigation.

Supposing the named targeting is scoped to BCGs, are there any concerns with the proposal itself?

[annevk]

Taking a step back, it seems that the problem here is that Chromium started making BCG swaps that are not okay per the specification. Perhaps I misremember, but I thought the idea was that we'd only make BCG swaps for address-bar-driven navigations or when they would not be observable. If the BCG's browsing context set holds more than one entry, you can't really swap for ordinary (clicking a link) navigations.

[kjmcnee]

Both Chromium and Firefox (see here) perform a swap when there are no other windows in the BCG, at the time of the navigation. This check for other windows was believed (as far as I can tell, I can't speak for the original authors) to make these swaps not observable. As it turns out, there was a case that caused these to be observable, due to the opener relationship not being established until after the navigation which performs the swap.

Note that simply reverting this swap behaviour isn't viable, for the reason mentioned in the Considered alternatives section.