Re: [w3ctag/design-reviews] Early design review: Future browsing context group dependency hint (Issue #979)

Hello.

> Why do you see rel=opener as the right approach, rather than by keying on target=<anything>? That a new window with target= will not be discoverable is surprising.

To hopefully clarify, the anchor that targets a new window is not where the BCG change happens. A previous navigation changed the BCG and the anchor for that needs the proposed relation. Consider the example in the background [section](https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint#background) of the linked explainer. The link for Step 1 produces a regular forward navigation (implicitly target=_self). Several years ago, chromium and firefox started making navigations like this change BCGs, when there is no existing opener. This was done as part of the implementation of bfcache. In the chromium implementation's case at least, this BCG change is necessary to be able to bfcache the referring page.

After the BCG change happens in Step 1, Step 2 opens a popup in the new BCG. The new window at this point is still discoverable. After a back navigation happens (Step 3), we return to the referring page and its BCG. Since the BCG of the referring page and the page that opened the popup are different, the referring page can't target the popup (Step 4). Named targeting is scoped to BCGs.

The proposed use of rel=opener goes on the link in Step 1 to prevent the BCG change. The new window is created later and by that point it's too late to undo the BCG change. In other words, the rel=opener needs to go on the anchor that links to a page that opens a window, if it wants to retain the opener relationship across a back navigation.

I can't speak for the original authors who introduced these BCG changes, but I assume that the BCG changes were believed to not be web visible due to the check for existing windows. As it turns out, this was not the case. This proposal intends to offer a way for site authors to address breakage from that.

> an explicit rel=opener as an explicit request to stay in the same BCG seems like it has some awkward consequences.

Just to clarify, rel=opener is not new to this proposal. It was introduced [here](https://github.com/whatwg/html/issues/4078). This proposal introduces semantics for _self navigations. So I think this part of the concern isn't new to this proposal. Indeed, part of my thinking around choosing rel=opener was the similarity with the trade-off made there.

> Concretely, what do we stand to lose if we insist that new windows stay in the same group? Are there performance numbers that motivate having a process switch?

To clarify, the previous change was motivated by bfcache eligibility, not process allocation.

See [this point](https://github.com/explainers-by-googlers/future-browsing-context-group-dependency-hint?tab=readme-ov-file#do-not-perform-proactive-browsing-context-group-changes) in considered alternatives. Reverting the BCG changes by bfcache implementations would severely reduce the usefulness of bfcache. I don't have bfcache metrics on hand, but it is quite clear from side by side comparisons that bfcache offers significant performance improvements.

> Maybe WebKit's behavior is evidence that the costs are acceptable.

WebKit's bfcache implementation does not require BCG changes. While this would be ideal for all bfcache implementations, it is unfortunately infeasible (at least for the chromium implementation).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/979#issuecomment-2403549065
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/979/2403549065@github.com>