New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 617755 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Buried. Ping if important.
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

window.open("", "nameOfExistingWindow") creates a new window (if called from window created via rel="noreferrer")

Project Member Reported by lukasza@chromium.org, Jun 6 2016

Issue description

Repro steps:
1. Change TestRunner::canOpenWindows() to always return "true"
   (this behavior is not the default in tests, but this is what browser users would see).
2. Build layout tests (i.e. $ ninja -C out/gn_no_asan ... blink_tests).
3. Run no-referrer-target-blank.html test:

$ DISPLAY=:20 third_party/WebKit/Tools/Scripts/run-webkit-tests -t gn_no_asan -v --no-retry-failures --additional-drt-flag=--no-sandbox --iterations=1 http/tests/navigation/no-referrer-target-blank.html


Expected behavior:

window.open("", "consoleWindow") called by no-referrer-helper.php should find and return a window proxy for the main test window (just as it does in http/tests/navigation/no-referrer-subframe.html test).


Actual behavior:

window.open("", "consoleWindow") creates a new window.
 
If I delete rel="noreferrer" from no-referrer-target-blank.html, then window.open("", "consoleWindow") behaves as expected and returns a window proxy to the main test window.

Note that the broken behavior (not finding the window in rel="noreferrer" case) repros with and without --site-per-process mode - in both modes, no-referrer-helper.php link will open in a new renderer process.
I am not sure if I am able to fully comprehend the spec for window.open (https://www.w3.org/TR/html5/browsers.html#dom-open).  OTOH, I do note that the spec doesn't mention rel="noreferrer" and therefore I think presence of the |rel| attribute should not impact behavior of window.open.

The spec for rel=noreferrer (https://www.w3.org/TR/html5/links.html#link-type-noreferrer) says that window.opener should be null, but in the repro steps here the opened document refers to the opener via its window name (the name which it has learned about via an offline channel, not via referrer and/or opener relationship).
Cc: mkwst@chromium.org
mkwst@, can you take a look please?  alexmos@ says that you might be the person for the initial triage of this bug (?) given that you've worked on the initial noreferrer support.
BTW: Note that no-referrer-target-blank-expected.txt used to verify referrer and window.opener, but (because of this issue with window.open?) this verification was removed in:

https://chromium.googlesource.com/chromium/src/+/7091fc746a8d0e51115a9e3d986d2e0f1949e604

Diff of no-referrer-target-blank-expected.txt:

https://chromium.googlesource.com/chromium/src/+/7091fc746a8d0e51115a9e3d986d2e0f1949e604%5E%21/#F20
Cc: creis@chromium.org
Components: Internals>Sandbox>SiteIsolation
Labels: OS-All
Also +creis@, since this touches on  issue 69267 , where noreferrer windows were explicitly put into a new SiteInstance and BrowsingInstance, even for same-site links.  See also the SwapProcessWithSameSiteRelNoreferrer test.

Quoting that issue: "It's already true that the new window cannot script its opener window (since window.opener isn't set), and the parent is opting in to extra isolation by using rel=noreferrer."

The question is, should the new window still be able to discover and script the opener window using that window's name, if it is set?

Comment 6 by creis@chromium.org, Jun 6 2016

No, the new window should not be able to discover and script its opener after rel=noreferrer (or rel=noopener) using the opener's name, at least to my knowledge.  The intention was to isolate the opener from the new window.
Do we want to clarify the spec, so that it explicitly says that rel=noreferrer should disable finding the opener via window.open?  Right now https://www.w3.org/TR/html5/links.html#link-type-noreferrer doesn't talk about this.
Cc: -mkwst@chromium.org
Owner: mkwst@chromium.org
Status: Assigned (was: Untriaged)

Comment 9 by creis@chromium.org, Oct 14 2016

Comment 7: I'm not sure this needs an explicit mention in the spec, though I'm not opposed to it.  It may depend on how other browsers behave, though.

In Chrome's case, window names are specific to their BrowsingInstance (i.e., unit of related browsing contexts), rather than global to the whole browser.  I don't think this is true in other browsers, but it explains why rel=noreferrer (which creates a new BrowsingInstance) doesn't find existing window names in Chrome.

Sign in to add a comment