Intent to implement and ship: rel="noopener" on links

Boris Zbarsky

unread,

Apr 25, 2016, 2:09:07 PM4/25/16

to

Summary: The idea is to be able to write

<a target="_blank" rel="noopener" href="someone-I-don't-trust">Go
there</a>

and not have "someone-I-don't-trust" be able to get hold of your window
via window.opener.

This is already possible with rel="noreferrer", but that also prevents
sending a referrer, which is undesirable in cases like search engine
result pages.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267339

Link to standard: https://html.spec.whatwg.org/#following-hyperlinks-2
step 4.

Platform coverage: all platforms.

Estimated or target release: Firefox 48 or 49 depending on how long this
discussion and reviews take.

Preference behind which this will be implemented: None.

Support in other engines: Supported in Blink. Not sure about others.

Possible issues:

1) This is not feature-detectible, as far as I can see. So it's not
clear to me that sites will know they can use this, short of relying on
browser sniffing.
2) Unlike Blink we are _not_ implementing the window.open feature yet.
That's tracked in
<https://bugzilla.mozilla.org/show_bug.cgi?id=1267339>. This is either
mitigated or exacerbated by issue #1, depending on how you want to look
at it....

-Boris

Tanvi Vyas

unread,

Apr 25, 2016, 2:57:41 PM4/25/16

to Boris Zbarsky, dev-pl...@lists.mozilla.org

Very cool! Thanks for implementing.

On 4/25/16 11:09 AM, Boris Zbarsky wrote:
> Summary: The idea is to be able to write
>
> <a target="_blank" rel="noopener" href="someone-I-don't-trust">Go
> there</a>
>
> and not have "someone-I-don't-trust" be able to get hold of your
> window via window.opener.
>
> This is already possible with rel="noreferrer", but that also prevents
> sending a referrer, which is undesirable in cases like search engine
> result pages.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267339

I think you meant to link to bug
https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 here.

Boris Zbarsky

unread,

Apr 25, 2016, 3:07:50 PM4/25/16

to

On 4/25/16 2:57 PM, Tanvi Vyas wrote:
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1267339
> I think you meant to link to bug
> https://bugzilla.mozilla.org/show_bug.cgi?id=1222516 here.

Er... right you are. Too many identical-looking tabs. ;)

-Boris

Domenic Denicola

unread,

Apr 25, 2016, 10:31:47 PM4/25/16

to

On Monday, April 25, 2016 at 2:09:07 PM UTC-4, Boris Zbarsky wrote:

> 1) This is not feature-detectible, as far as I can see. So it's not
> clear to me that sites will know they can use this, short of relying on
> browser sniffing.

If you implement DOMTokenList.prototype.supports, it should be; supports was added specifically for this use case.

Boris Zbarsky

unread,

Apr 25, 2016, 10:47:33 PM4/25/16

to

Ah. Perhaps we should hold off on doing this until
https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 is fixed then. And
the window.open thing would still not be detectable, so people would
probably start assuming the anchor bit implied the window thing. :(

-Boris

Boris Zbarsky

unread,

May 3, 2016, 3:28:49 PM5/3/16

to

On 4/25/16 10:47 PM, Boris Zbarsky wrote:
> Ah. Perhaps we should hold off on doing this until
> https://bugzilla.mozilla.org/show_bug.cgi?id=1257849 is fixed then. And
> the window.open thing would still not be detectable, so people would
> probably start assuming the anchor bit implied the window thing. :(

Looks like Chrome doesn't actually implement
HTMLAnchorElement.prototype.relList, so this can't be feature-detected
anyway by sites. They have to rely on browser sniffing.

So I guess we can do whatever we want here, since sites are screwed
anyway. :(

-Boris