Able to repro this issue on Windows 7, MAC (10.11.6) & Ubuntu Trusty (14.04) for Google Chrome Stable Version - 53.0.2785.143

This is a Non-Regression issue existing from M30 - # 30.0.1549.0

mkwst@, CCing you on all these because they are all in the same code.

Here's a fiddle to play with:

https://jsfiddle.net/ry9uh11n/

The a.click isn't navigating the window. When I put the link in the document and click on it, there's another new window with null opener.

FWIW, when I run that Fiddle in FF 50.0.2, after clicking on the link it writes [object Window] into the document. So it looks like FF doesn't reset opener sometimes when reusing windows.

What component do I put on things which probably belong to core/frame?

> FWIW, when I run that Fiddle in FF 50.0.2

noopener support landed in Gecko for Firefox 52, for what it's worth.  So testing the behavior of noopener testcases in 50.x is not very useful.  ;)

Sigh, around we go. I sometimes think we are missing a component for things in core/frame around navigation.

This is a bug. We should fix it.

Bulk disowning per sshruthi's email about bug triage best practices.

I'll take this bug.

This is tricky to find an interoperable behavior, browsers don't agree on the corner cases. I have an experimental CL here https://chromium-review.googlesource.com/c/chromium/src/+/734234 that fixes the behavior in comment #1, but there are still issues.

In particular:
* What to do for targeted subframe navigations? Firefox will open a new tab/window for targeted subframe navigations with noopener, Chrome/Edge won't. No browsers will open a new window for targeted noreferrer navigations (even Firefox). The spec says that noreferrer should imply noopener (https://html.spec.whatwg.org/#link-type-noreferrer), but Firefox is not consistent here. Chrome has a layout test that fails when disowning targeted subframe navigations with noreferrer (http/tests/navigation/no-referrer-subframe.html).

* When disowning an opener, should the opener still be reachable by name? The spec says (https://html.spec.whatwg.org/#disowned-its-opener) "If a browsing context has disowned its opener, the value of its window.opener is null. That prevents scripts in the browsing context from changing any properties of its opener browsing context's Window". Does that only mean preventing scripts through window.opener, or in general? The behavior here is very different accross browsers: Edge respects noreferrer by nulling the opener, but always allows windows to be reached by name. Chrome and Firefox won't allow windows to be reached by name when their owner is disowned.

Overall, it's not totally clear to me that Chrome is violating the spec, and some of the points about navigating in the spec should be clarified.

For example, in https://html.spec.whatwg.org/#following-hyperlinks
"7. Let target and replace be the result of applying the rules for choosing a browsing context given targetAttributeValue, source, and noopener.

8. If target is null, then return.

9. If noopener and replace are true, then disown target's opener."

'replace' doesn't seem to be specified in https://html.spec.whatwg.org/#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name .

I'll open a spec bug about this issue and follow-up there.

> browsers don't agree on the corner cases

Right, see https://github.com/whatwg/html/issues/1826 where we agreed on a behavior and then Chrome dropped the ball.   All that stuff has been blocked forever on someone on the Chrome team actually engaging or something.

> What to do for targeted subframe navigations? 

This was covered in the abovementioned discussion.

> The spec says that noreferrer should imply noopener

This is not web-compatible given how we want noopener to affect targeting.  See abovementioned discussion.

Basically, you should ignore the current text for noopener in the HTML spec.  It doesn't represent the last consensus we had on this.

> Chrome and Firefox won't allow windows to be reached by name when their owner is disowned

This is the intended behavior.

> Overall, it's not totally clear to me that Chrome is violating the spec

It's violating the agreement that was reached, which hasn't made it into the spec, because Chrome hasn't committed to actually implementing it.

And to be clear, this issues was filed on a case in which Chrome's behavior (at the time and now) differed from the behavior Mike West was proposing at the time.

Ah, this make sense. Thanks for the clarification. I've sent an intent to ship this on blink (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/Ucy5woezBFY) and match Firefox's behavior.

Tentative CL is here https://chromium-review.googlesource.com/c/chromium/src/+/734234 and passes the wpt tests mentioned in the whatwg discussion (htmlanchorelement_noopener).