Give top-level browsing contexts their own browsing context name bucket

[annevk]

This basically comes down to defining the name bucket as part of https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-browsing-contexts, maybe even https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-similar-origin-browsing-contexts?

This should also allow for the removal of vagueness in step 4 of https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name.

Having said that, it might not be that easy since the first bullet point of https://html.spec.whatwg.org/multipage/browsers.html#familiar-with will now be false.

Copying @bobowen. @jgraham any idea how to test having two pages open that then window.open() something with the same name and ensure we now have four pages open? Manual test only?

[bobowen]

Couldn't we open the second test page from the first and then have it set its opener to null?

Given the definition of directly reachable browsing contexts that would seem to split them into two separate groups.

[zcorpan]

I don't quite follow what it is you want to test, but you can use postMessage or storage events to communicate test result to the "main" window.

[annevk]

I need multiple open top-level browsing contexts. Ideally not created through window.open() as then we start to depend on the particulars of that, which are still a little hazy. (Though as far as name sharing goes that should indeed probably stop once set to null.)

[zcorpan]

The wpt environment should have the popup blocker disabled, so you could use <a target=_blank href=other.html rel=noopener> and click() it.

[annevk]

cc @freesamael

[annevk]

Having thought about this some more and discussed with @freesamael on IRC, a change we could make soonish (if agreed I would put it on top of #2618) is to replace

If the given browsing context name is not _blank and there exists a browsing context whose name is the same as the given browsing context name, and the current browsing context is familiar with that browsing context, and the user agent determines that the two browsing contexts are related enough that it is ok if they reach each other, then that browsing context must be the chosen one. If there are multiple matching browsing contexts, the user agent should select one in some arbitrary consistent manner, such as the most recently opened, most recently focused, or more closely related.

with a search for the given browsing context name in current browsing context's unit of related browsing contexts.

Even if familiar with would still return true across units of related browsing contexts I don't think that's problematic since we basically wouldn't be looking at those.

This is effectively what Firefox (recently) and Chrome (also recently) implement per:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1357845
• https://bugs.chromium.org/p/chromium/issues/detail?id=658386

---

We should perhaps investigate though if we can go further. If I'm on "https://example.com/" and then navigate to "https://example.invalid/" which opens a named browsing context "x". If I then go back from "https://example.invalid/" should "https://example.com/" have access to "x"? It's rather sad leakage.

cc @mikewest @johnwilander

(FWIW, I'm also planning on making "unit of related browsing contexts" a more imperative construct. That is basically being filled up as browsing contexts are created. That also makes it more clear when it is created and what state is associated with it.)

[annevk]

The other question I have for implementers is how they deal with #1509? Is that basically dealt with if you restrict the search to "unit of related browsing contexts" or do we need something in addition to that?

[mystor]

It would be nice if we could go further than just the unit of related browsing context in terms of making it such that some navigations would cause the browsing context to leave its current unit of related browsing contexts (and thus cause all references to it to be disowned). This new window would then be completely independent as though it was opened in a brand new tab.

For web compat reasons it might be nice to allow history navigations to restore the browsing context into its previous unit of related browsing contexts, re-establishing any window references and returning it to its previous window namespace. I imagine that specifying that behavior would be difficult, however.

It might be easier to specify this as certain navigations destroying the old browsing context, and creating a new one which shares the old browsing context's session history, session storage (maybe?), and other session information, and is displayed in the same tab or window.

The navigations which I would be thinking of changing would be ones like:
<a href="..." rel="noopener" target="_top"> (though this may not be web-compatible - I'm not sure) and UI triggered navigations, such as opening a bookmark, or navigating to a URL from the URL bar.

[annevk]

Which navigations are you thinking of? If we'd only do this when there are no auxiliary browsing contexts it would be quite easy, I think. If we need to break ties with auxiliary browsing contexts that would indeed be harder as you need to define some new kind of WindowProxy behavior, though we might need to do that anyway for the isolation work that's going on.

(I'm hoping to make the "unit of related browsing contexts" story much more explicit which should allow us to make more radical changes more easily, but it's still early days.)

[annevk]

In fact, it might be good to split this in two parts:

1. Align the standard with Chrome and Firefox and only search for names within the same "unit of related browsing contexts".
2. Open a new issue for more ambitious separation.

[mystor]

If I remember correctly, when we don't have any auxiliary browsing contexts, we can already move the window into a new unit of related browsing contexts after a toplevel load, as there are no windows which will survive the navigation, so moving it to a new one is identical to leaving it in the current one.

The interesting case is to do this when there are auxiliary browsing contexts which will lose access if the browsing context leaves the current unit of related browsing contexts. This would definitely require a new kind of WindowProxy behavior, but would give browsers more ability to shuffle windows between browsers.

I agree this would be better in a new issue. I've filed #2635 about it.

[annevk]

Let's merge this into #313. (#4198 will also help with this.)