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

Open
annevk opened this Issue Jun 20, 2016 · 11 comments

Comments

4 participants
@annevk
Member

annevk commented Jun 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bobowen

bobowen Jun 21, 2016

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.

bobowen commented Jun 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Jun 21, 2016

Member

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.

Member

zcorpan commented Jun 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Jun 21, 2016

Member

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

Member

annevk commented Jun 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Jun 21, 2016

Member

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

Member

zcorpan commented Jun 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
Member

annevk commented May 4, 2017

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk May 4, 2017

Member

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:


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

Member

annevk commented May 4, 2017

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:


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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk May 4, 2017

Member

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?

Member

annevk commented May 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mystor

mystor May 4, 2017

Contributor

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.

Contributor

mystor commented May 4, 2017

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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk May 5, 2017

Member

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

Member

annevk commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk May 5, 2017

Member

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

annevk commented May 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mystor

mystor May 5, 2017

Contributor

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.

Contributor

mystor commented 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 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 added a commit that referenced this issue May 9, 2017

Revamp the rules for choosing a browsing context
This makes several changes:

* Stop throwing an exception in `<a>` and `<area>` activation behavior as a
  result of popup blocking as it doesn’t match implementations. Fixes #2616. 
  Formal testing is not possible and tracked by
  web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes #2443.
* Centralize all user-configurable behavior instead of having it
  duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: #1440.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.

inikulin added a commit to HTMLParseErrorWG/html that referenced this issue May 9, 2017

Revamp the rules for choosing a browsing context
This makes several changes:

* Stop throwing an exception in `<a>` and `<area>` activation behavior as a
  result of popup blocking as it doesn’t match implementations. Fixes #2616. 
  Formal testing is not possible and tracked by
  web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes #2443.
* Centralize all user-configurable behavior instead of having it
  duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: #1440.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.

inikulin added a commit to HTMLParseErrorWG/html that referenced this issue May 9, 2017

Revamp the rules for choosing a browsing context
This makes several changes:

* Stop throwing an exception in `<a>` and `<area>` activation behavior as a
  result of popup blocking as it doesn’t match implementations. Fixes #2616. 
  Formal testing is not possible and tracked by
  web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes #2443.
* Centralize all user-configurable behavior instead of having it
  duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: #1440.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment