Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements

[Andrea Marchesini]

*Summary*: WebKit is experimenting an interesting feature: target=_blank on
anchor and area elements implies ref=noopener.
https://trac.webkit.org/changeset/237144/webkit/

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

*Link to standard*: https://github.com/whatwg/html/issues/4078

*Platform coverage*: everywhere.

*Estimated or target release*: 66 - after 1 cycle with this feature enabled
in nightly and beta only.

*Preference behind which this will be implemented*
:dom.targetBlankNoOpener.enabled

*Is this feature enabled by default in sandboxed iframes?* yes.

*DevTools bug*: no special support for devtools. Maybe we could dispatch an
Intervention report via Reporting API.

*Do other browser engines implement this?* Only safari at the moment:
https://trac.webkit.org/changeset/237144/webkit

*web-platform-tests*: none, yet, but I can convert my mochitest in a WPT
easily.

*Is this feature restricted to secure contexts?* no needs.

[Alex Gaynor]

I'm very excited about this -- in my experience very few developers know
about the dangers of target=_blank.

Do we have any sense of how large the breakage will be, and do we have any
docs for developers who are impacted? (I assume rel=opener is the fix?)

Yay!

Alex

On Wed, Nov 21, 2018 at 3:29 AM Andrea Marchesini <amarc...@mozilla.com>
wrote:

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Anne van Kesteren]

On Wed, Nov 21, 2018 at 4:08 PM Alex Gaynor <aga...@mozilla.com> wrote:
> Do we have any sense of how large the breakage will be, and do we have any
> docs for developers who are impacted? (I assume rel=opener is the fix?)

The "fix" would be to use target=someuniquename.

And I don't think there's data, other than Safari folks not having
heard anything yet.

[Daniel Veditz]

On Wed, Nov 21, 2018 at 7:08 AM Alex Gaynor <aga...@mozilla.com> wrote:

> Do we have any sense of how large the breakage will be, and do we have any
> docs for developers who are impacted? (I assume rel=opener is the fix?)
>

"opener" doesn't exist, and we shouldn't need it. You'd specify a target
name other than "_blank" to indicate it's a context you care about -- only
"_blank" gets the new behavior.

-Dan Veditz

[Boris Zbarsky]

On 11/21/18 2:22 PM, Daniel Veditz wrote:
> "opener" doesn't exist

It does in WebKit's proposed changes and in our implementation of them.

> You'd specify a target
> name other than "_blank" to indicate it's a context you care about

This seems backwards. What matters is whether the context should care
about _you_, not whether you care about it. If you want to open a
guaranteed-new context that can then communicate with you, how should
you do that, exactly? Making up target names (which you have no way to
guarantee are unique) seems like a bad approach to that.

-Boris

[Ehsan Akhgari]

On Wed, Nov 21, 2018 at 3:55 PM Boris Zbarsky <bzba...@mit.edu> wrote:

> On 11/21/18 2:22 PM, Daniel Veditz wrote:
> > "opener" doesn't exist
>
> It does in WebKit's proposed changes and in our implementation of them.
>
> > You'd specify a target
> > name other than "_blank" to indicate it's a context you care about
>
> This seems backwards. What matters is whether the context should care
> about _you_, not whether you care about it. If you want to open a
> guaranteed-new context that can then communicate with you, how should
> you do that, exactly?
>

Would it be OK if the answer to that question be "use window.open()"?

It would really be nice if browsers could converge on a definition of what
these conditions are going to be, and I would be really happy the more
restrictive the cases we hand out window.opener references can be. Having
a programmatic way (i.e. an API call) as the only access point to this
functionality has the nice side benefit that if the browser wants to
provide interventions in the creation of opener references, we would have
only a single API call to worry about, rather than having to keep track of
things like tabs opened from links. In fact, one motivation beyond this
intent thread is one future anti-tracking intervention that we've been
discussing.

Cheers,
--
Ehsan

[Boris Zbarsky]

On 11/21/18 11:50 PM, Ehsan Akhgari wrote:
> Would it be OK if the answer to that question be "use window.open()"?

Can one do noreferrer with window.open()?

Also, if your thing doing the navigation is a <form>, not <a>, then
window.open is pretty hard to use for that. Then again, <form
target="_blank"> is not that common...

-Boris

[Ehsan Akhgari]

On Wed, Nov 21, 2018 at 11:55 PM Boris Zbarsky <bzba...@mit.edu> wrote:

> On 11/21/18 11:50 PM, Ehsan Akhgari wrote:
> > Would it be OK if the answer to that question be "use window.open()"?
>
> Can one do noreferrer with window.open()?
>

Yes, by passing 'noopener' in the features argument:
https://html.spec.whatwg.org/multipage/window-object.html#apis-for-creating-and-navigating-browsing-contexts-by-name:disowned-its-opener
.

> Also, if your thing doing the navigation is a <form>, not <a>, then
> window.open is pretty hard to use for that. Then again, <form
> target="_blank"> is not that common...
>

That's true, this wouldn't cover the form submission use case.

Which reminds me, it's impossible to block opener reference creation upon
form submission right now as far as I can tell. This is actually a bug in
the spec. <
https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#form-submission-algorithm:the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name>
calls into "rules for choosing a browsing context" passing only two
arguments, omitting the third one (noopener) <
https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name
>.

I wonder if it makes sense to make a similar change here, to make <form
target="_blank"> imply noopener behaviour and then if that proves to be Web
compatible, propose to change the spec to pass false there?

Cheers,
Ehsan
--
Ehsan

[Anne van Kesteren]

On Thu, Nov 22, 2018 at 7:07 AM Ehsan Akhgari <ehsan....@gmail.com> wrote:
> I wonder if it makes sense to make a similar change here, to make <form
> target="_blank"> imply noopener behaviour and then if that proves to be Web
> compatible, propose to change the spec to pass false there?

Yeah, I think we should try to keep it consistent. I think Apple was
worried that <form> would be the least likely to be web-compatible, so
they started out smaller.

[Boris Zbarsky]

On 11/22/18 1:06 AM, Ehsan Akhgari wrote:
>> Can one do noreferrer with window.open()?
>>
>
> Yes, by passing 'noopener' in the features argument:
> https://html.spec.whatwg.org/multipage/window-object.html#apis-for-creating-and-navigating-browsing-contexts-by-name:disowned-its-opener

But we're trying to _have_ an opener; that's why we're here to start
with. We're talking about noreferrer.

> Which reminds me, it's impossible to block opener reference creation upon
> form submission right now as far as I can tell.

Yes. Right now <form> doesn't have a thing like "rel" to pass along
directives like "noopener". Maybe we should get that fixed in the spec
somehow.

> I wonder if it makes sense to make a similar change here, to make <form
> target="_blank"> imply noopener behaviour and then if that proves to be Web
> compatible, propose to change the spec to pass false there?

It might indeed.

-Boris

[Ehsan Akhgari]

On Thu, Nov 22, 2018 at 10:55 AM Boris Zbarsky <bzba...@mit.edu> wrote:

> On 11/22/18 1:06 AM, Ehsan Akhgari wrote:
> >> Can one do noreferrer with window.open()?
> >>
> >
> > Yes, by passing 'noopener' in the features argument:
> >
> https://html.spec.whatwg.org/multipage/window-object.html#apis-for-creating-and-navigating-browsing-contexts-by-name:disowned-its-opener
>
> But we're trying to _have_ an opener; that's why we're here to start
> with. We're talking about noreferrer.
>

My apologies, I misread your previous email as saying "Can one do noopener"
:-/

Indeed, specifying noreferrer isn't currently possible. I think that is a
desirable feature to add to window.open().

> > Which reminds me, it's impossible to block opener reference creation upon
> > form submission right now as far as I can tell.
>
> Yes. Right now <form> doesn't have a thing like "rel" to pass along
> directives like "noopener". Maybe we should get that fixed in the spec
> somehow.
>

Do you mean adding a rel attribute to <form>? Not sure if all of the other
link type values for rel make sense for <form> but having some way of
passing "noopener" (and "opener" for that matter) directives for <form> is
indeed something that we should probably look into doing, especially when
it comes to changing the default behavior of <form target=_blank>. I have
no good ideas for how to do it other than inventing yet a new attribute...

> > I wonder if it makes sense to make a similar change here, to make <form
> > target="_blank"> imply noopener behaviour and then if that proves to be
> Web
> > compatible, propose to change the spec to pass false there?
>
> It might indeed.
>

Talked to baku and annevk a bit also, and I guess there is one way to know
the web compat impact, so I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1509346.

Cheers,
--
Ehsan

[Anne van Kesteren]

On Thu, Nov 22, 2018 at 6:00 PM Ehsan Akhgari <ehsan....@gmail.com> wrote:
> Do you mean adding a rel attribute to <form>? Not sure if all of the other
> link type values for rel make sense for <form> but having some way of
> passing "noopener" (and "opener" for that matter) directives for <form> is
> indeed something that we should probably look into doing, especially when
> it comes to changing the default behavior of <form target=_blank>. I have
> no good ideas for how to do it other than inventing yet a new attribute...

Since <form> is effectively a more complicated <a>, adding rel=""
seems very reasonable to me ("noreferrer", "noopener", "search",
"help", and "nofollow" make some amount of sense there).
https://github.com/whatwg/html/issues/2983 tracks this standards-wise.
(They also request <base rel> there, not sure about that one given how
annoying global mutable state is.)