Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Give top-level browsing contexts their own browsing context name bucket #1440
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.
I need multiple open top-level browsing contexts. Ideally not created through
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:
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.
(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.)
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:
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
(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.)
referenced this issue
May 5, 2017
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
I agree this would be better in a new issue. I've filed #2635 about it.