Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
On Thu, Nov 22, 2018 at 6:00 PM Ehsan Akhgari wrote:
> Do you mean adding a rel attribute to ? Not sure if all of the other
> link type values for rel make sense for but having some way of
> passing "noopener" (and "opener" for that matter) directives for is
> indeed something that we should probably look into doing, especially when
> it comes to changing the default behavior of . I have
> no good ideas for how to do it other than inventing yet a new attribute...
Since is effectively a more complicated , 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 there, not sure about that one given how
annoying global mutable state is.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
On Thu, Nov 22, 2018 at 10:55 AM Boris Zbarsky 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 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 ? Not sure if all of the other link type values for rel make sense for but having some way of passing "noopener" (and "opener" for that matter) directives for is indeed something that we should probably look into doing, especially when it comes to changing the default behavior of . 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 > 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
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 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 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
On Thu, Nov 22, 2018 at 7:07 AM Ehsan Akhgari wrote: > I wonder if it makes sense to make a similar change here, to make 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 would be the least likely to be web-compatible, so they started out smaller. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
On Wed, Nov 21, 2018 at 11:55 PM Boris Zbarsky 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 , not , then > window.open is pretty hard to use for that. Then again, 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 imply noopener behaviour and then if that proves to be Web compatible, propose to change the spec to pass false there? Cheers, Ehsan -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
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 , not , then window.open is pretty hard to use for that. Then again, target="_blank"> is not that common... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
On Wed, Nov 21, 2018 at 3:55 PM Boris Zbarsky 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
On Wed, Nov 21, 2018 at 7:08 AM Alex Gaynor 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
On Wed, Nov 21, 2018 at 4:08 PM Alex Gaynor 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
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 wrote: > *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. > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: implicit ref=noopener for target=_blank on anchor and area elements
*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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
