Why is this the right change to ask websites to make?

Why is it that we ask sites to make this change in order to have things work as they expected. That is, if a site sets target=foo, why would that window end up in a new BCG? Why is rel=opener the right way to address this, rather than target=foo?

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

</blockquote>

They got back to us; the end of their comment says the following:

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

Tess: If this is a Chrome-only problem, shouldn't they simply pursue a Chrome-only solution? Why standardize something at all here?

Jeffrey: If we do nothing, Chrome might ship this. Does this matter?

Martin: Firefox does this too.

Peter: This might pollute the web with unnecessary API surface. Sites might become locked into depending on this implementation quirk.

Tess: Sites can come to depend on Chrome's behavior. No obvious risk from this, but that might lead to issues.

Action on Martin to check with Gecko.

Martin: Mozilla folk's conclusion is that the target= thing is a bug. Browser context group switches should not be visible to content, so if content gives a window a name, and you switch back, and the name is still used in the back-forward cache, then it's a bug. Mozilla will fix the bug: if someone opens a named window, that invalidates the back/forward cache. Apple doesn't switch browser context groups, so they can keep that.

Jeffrey: So if Chrome has data showing it's important to keep the bf cache, Mozilla might reconsider.

Martin: Yes, but that probably won't happen.

unsatisfied:

<blockquote>

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.

</blockquote>