Make target=_blank imply noopener; support opener

[annevk]

This reduces the number of coupled top-level browsing contexts and thereby reduces the attack surface somewhat.

Tests: ...

Fixes #4078.

---

/index.html ( diff )
/links.html ( diff )

[annevk]

This is already implemented by Firefox and Safari (automated tests don't work due to lack of BroadcastChannel).

Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=927340.

[domenic]

Copypasta is bad; other requests are a bonus.

[domenic]

Tests for this will be important. It seems like you'll want to test the entire matrix of:

• noreferrer present vs. absent
• noopener present vs. absent
• opener present vs. absent
• target=_blank vs. target=something else (and maybe vs. no target)

[domenic]

LGTM with nits

[annevk]

cc @whatwg/documentation

[matatk]

Hello. I've been reviewing changes to HTML on behalf of the W3C's Accessible Platform Architectures Working Group, and had some questions about this change.

Regarding the behaviour illustrated in the opener example: if navigation occurs in a different tab or window to the one in which the focus lies, then users of assistive technologies (specifically screen readers or magnifiers) may not be made aware of that navigation in the other tab/window.

I tested in IE 11, Firefox 70 and Chrome 78, with NVDA 2019.2.1 and JAWS 2019, as well as Safari and VoiceOver on macOS Mojave, and found the same behaviour in all combinations of browser and screen-reader:

• Opening a pop-up link normally (defaults to new tab): the 'pop-up' could control the window.location of its opener, but this was not announced by the screen-reader.
• Opening the pop-up in a new window: the pop-up could not control its opener.

I realise that this PR only tweaks the implementation, rather than introducing the potential accessibility issues. Further, perhaps this would more naturally fall under the scope of WCAG than the HTML spec. However, I was wondering...

• Do you feel it may be appropriate to add a note near the example about the accessibility considerations?
• Would it be helpful if UAs provided notice of navigation in a different browsing context that has been triggered from the current one?
• Do you feel it should be down to the author of the page to decide if and how to provide that notification?

If the answer is 'yes' to any of the above, and you'd like a PR to amend the wording, I'd be happy to file one.

Other opener-related commits I found in the review: cf483d3 and c0b75ea.

cc @whatwg/a11y

[annevk]

@matatk I recommend filing a new issue. It's not entirely clear to me what you're suggesting screen reader technology does for noopener vs a normal popup so maybe clarify that there. Also, would you like to join the a11y team?

[matatk]

Hi @annevk, thanks for your reply. To clarify a bit: I don't think this is a new problem that was introduced by this PR—it seems it was the situation all along, but as I've rarely seen pop-ups that navigate their openers in the wild, I'd not noticed it until I looked into this change.

I'll be AFK for a few days, but when back I'll do a bit more research (as I don't grok why newly-opened windows, as opposed to tabs, can't navigate their opener—I guess this is a facet of multiprocess browsers, but need to check) and make some suggestions in a new issue. If anything, it seems like adding a note about the accessibility implications would be most appropriate, but I'll file the issue and see what you think.

My cycles are somewhat limited, but I'd be happy to join the a11y team and see how it goes; hope I can be of help :-).