Hi @kjmcnee, we were discussing this and we're not following the reasoning.

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. That navigations will end up in a different process is similarly surprising. Obviously rel=noopener breaks that link and enables moving to a new process, but an explicit rel=opener as an explicit request to stay in the same BCG seems like it has some awkward consequences.

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? Maybe WebKit's behavior is evidence that the costs are acceptable. That might trade-off back-forward performance for straight-up loading performance, but I'm curious about what the real cost would be.

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 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. 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 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).

We discussed this in a breakout and with some Mozilla engineers, and we think it's probably best to drop the bf-cache optimization in the case that's driving the proposal here. If Chrome has data showing that it's important to keep the optimization in this case, we're open to reconsidering.

Attempting to support bfcache for the described scenario would indeed not be worthwhile. This proposal is not about supporting bfcache in this scenario. The problem is that we can't tell that we are in this scenario at the point of the first navigation. This proposal offers a way to selectively disable BCG changes (and therefore disable bfcache) for only cases like this.