Add a 'noopener' link attribute #290

mikewest · 2015-10-27T01:47:01Z

Based on Charlie Reis' proposal at 1, this patch adds a mechanism
by which web developers can open a new window without granting that
window access to the opener browsing context. This is possible today
via , but that is both obscure and
poorly explanatory. The attribute clarifies the behavior.

mikewest · 2015-10-27T01:47:42Z

Getting something like this into HTML might make it possible for Secure Contexts to distinguish between popups that could be secure contexts and popups that couldn't. WDYT, @annevk?

annevk · 2015-10-28T04:53:58Z

I think we should add some text that explains why you want to use this instead of noreferrer. Or the other way around.

mikewest · 2015-10-28T23:33:16Z

Simplified the patch, and added some text to noreferrer to note that it implies noopener in specific circumstances. Is that what you're looking for?

Basically, we just tacked completely unrelated functionality onto noreferrer at some point in ~2011. This is an attempt to explain the behavior, and make it available separately.

annevk · 2015-10-29T02:03:29Z

"Charlie Reis" needs to be added to the acknowledgements section too.

domenic · 2015-10-29T02:55:01Z

Can we also make sure a caniuse entry and web platform tests are in progress?

Do we have interest from more than one implementer?

mikewest · 2015-10-29T04:29:26Z

@rlbmoz, @dveditz: How do y'all feel about implementing this in Firefox? :)
@travisleithead, @jacobrossi: Ditto for Edge?
@rniwa: WebKit?

mikewest · 2015-11-05T14:02:02Z

Filed https://www.chromestatus.com/feature/5651874132787200, FWIW.

annevk · 2015-11-05T14:45:18Z

We need to credit @sc0ttbeardsley in Acknowledgements since he proposed this in https://lists.w3.org/Archives/Public/public-whatwg-archive/2015May/0046.html. Per http://logs.glob.uno/?c=mozilla%23content&s=5+Nov+2015&e=5+Nov+2015#c338410 at least some from Mozilla are on board with this feature.

annevk · 2015-11-05T14:48:28Z

source

-  <p>This keyword also <a href="#noopener">causes the <code data-x="dom-opener">opener</code>
-  attribute to remain null</a> if the hyperlink <span data-x="creating a new browsing context">creates</span> a new <span>browsing context</span>.</p>
+  <p class="note">For historical reasons, the <code data-x="rel-noreferrer">noreferrer</code>
+  attribute implies the behavior associated with the <code data-x="rel-noopener">noopener</code>


These are not the attributes you're looking for. (Keywords.)

Thanks, fixed.

mikewest · 2015-11-05T16:11:45Z

I added the window.opener changes I'd like to make, since they touched basically the same bits of the spec. Happy to split it out if you decide that it's simpler that way.

sc0ttbeardsley · 2015-11-05T17:51:43Z

Thanks for the tag @annevk. I have been chatting with Steve Workman at Mozilla (sorry, don't know his github) and his team was going to look into at least throwing a warning when window.opener is modified across origins (I think IE does this already).

@mikewest Here is the original bug I filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28821 (I suspect this PR should resolve that). Also it looks like http://crbug.com/69267 is related to http://crbug.com/168988

I just closed my PR on the wrong repo.

Regarding the proposal, I had thought about using "noopener" keyword but I think "newcontext" might be a bit more explicit. Ultimately we don't only want window.opener to be nullified, right? I think there is a desire to also do all of the other things (it might be hard to explicitly list everything though) associated with a new browsing context.

annevk · 2015-11-05T18:19:59Z

Note to self: file a bug against Gecko once this is merged.

annevk · 2015-11-05T18:33:15Z

source

+  <p class="note">For historical reasons, the <code data-x="rel-noreferrer">noreferrer</code>
+  keyword implies the behavior associated with the <code data-x="rel-noopener">noopener</code>
+  keyword when present on a hyperlink that <span
+  data-x="creating a new browsing context">creates</span> a new <span>browsing context</span>.


You are allowed to break inside an attribute value when it has spaces.

This document has seriously strange style rules.

annevk · 2015-11-05T18:42:08Z

@sc0ttbeardsley what other things are you thinking of that are not related to the browsing context having an opener browsing context (and therefore being auxiliary)?

sc0ttbeardsley · 2015-11-05T19:41:38Z

@annevk the original chromium bug mentioned running in a new "process". We should avoid getting so explicit that we dive into browser implementation variations on what constitutes a new browsing context. For instance, do all browsers equate new processes with new browsing contexts?

annevk · 2015-11-06T07:21:33Z

Either way it's a new browsing context. When the new browsing context has no opener it can run (in theory) in a distinct process since there's no synchronous script access to it.

mikewest · 2015-11-06T07:41:35Z

Refactored the patch a bit. WDYT, @annevk?

@sc0ttbeardsley: Thanks for the links to the chromium bugs. I've added some labels there.

annevk · 2015-11-06T16:18:57Z

source

+     <td><code data-x="rel-noopener">noopener</code></td>
+     <td><em>not allowed</em></td>
+     <td><span data-x="hyperlink annotation">Annotation</span></td>
+     <td>Requires that any <span>browsing context</span> created by following the hyperlink must not have a <span>opener browsing context</span>.</td>


annevk · 2015-11-06T16:23:18Z

I think with those nits this looks good. After this lands #313 will still need to be fixed to fully define the behavior added here accurately, correct?

mikewest · 2015-11-06T16:27:56Z

source

@@ -20968,6 +20968,11 @@ interface <dfn>HTMLHyperlinkElementUtils</dfn> {

   </li>

+   <li><p>If <var>subject</var>'s <a href="#linkTypes">link types</a> include the <code


Hrm. No? "types" is plural, so it doesn't "include". At least, "types includes" sounds strange.

Agreed. Misread.

mikewest · 2015-11-06T16:52:26Z

Squished. I didn't change "includes", but I will if you feel strongly about it.

Based on [Charlie Reis' proposal][1], this patch adds a mechanism by which web developers can open a new window without granting that window access to the opener browsing context. This is possible today via 'rel=noopener target=_blank', but that is both obscure and poorly explanatory. This patch adds a 'noopener' keyword to both hyperlinks and 'window.open' which clarifies the behavior and makes it available without side effects. [1]: https://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts

annevk · 2015-11-06T17:17:55Z

Ah, unfortunately this was not rebased so it did not merge completely cleanly. 2992ea9 is the commit.

annevk · 2015-11-06T17:18:18Z

Thank you though for your efforts!

annevk · 2015-11-06T17:36:56Z

Gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1222516.

sc0ttbeardsley · 2015-11-06T18:00:49Z

@annevk sorry, I see this is "closed" was the change not merged for some reason?

Oh, nevermind, I see the merge 2992ea9

THanks all!

awebdeveloper · 2016-03-28T07:09:03Z

webkit bug: https://bugs.webkit.org/show_bug.cgi?id=155166

awebdeveloper · 2016-03-28T07:09:20Z

IE bug: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/12942405-implement-rel-noopener

mikewest mentioned this pull request Oct 27, 2015

Reconsider popups as secure contexts. w3c/webappsec-secure-contexts#6

Closed

annevk added the needs implementer interest Moving the issue forward requires implementers to express interest label Nov 4, 2015

annevk reviewed Nov 5, 2015
View reviewed changes

annevk removed the needs implementer interest Moving the issue forward requires implementers to express interest label Nov 5, 2015

annevk reviewed Nov 6, 2015
View reviewed changes

mikewest reviewed Nov 6, 2015
View reviewed changes

annevk closed this Nov 6, 2015

annevk added a commit that referenced this pull request Nov 6, 2015

Per #290 window.open() can now return null

1cf1475

nwhittaker mentioned this pull request May 5, 2016

Support "rel" attribute johno/ember-linkify#18

Closed

Galixte mentioned this pull request Sep 6, 2017

Include rel=noopener rmcgirr83/elonw#12

Closed

domenic added topic: link topic: hyperlink and removed topic: link labels Jun 15, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a 'noopener' link attribute #290

Add a 'noopener' link attribute #290

mikewest commented Oct 27, 2015

mikewest commented Oct 27, 2015

annevk commented Oct 28, 2015

mikewest commented Oct 28, 2015

annevk commented Oct 29, 2015

domenic commented Oct 29, 2015

mikewest commented Oct 29, 2015

mikewest commented Nov 5, 2015

annevk commented Nov 5, 2015

annevk Nov 5, 2015

mikewest Nov 5, 2015

mikewest commented Nov 5, 2015

sc0ttbeardsley commented Nov 5, 2015

annevk commented Nov 5, 2015

annevk Nov 5, 2015

mikewest Nov 6, 2015

annevk commented Nov 5, 2015

sc0ttbeardsley commented Nov 5, 2015

annevk commented Nov 6, 2015

mikewest commented Nov 6, 2015

annevk Nov 6, 2015

mikewest Nov 6, 2015

annevk commented Nov 6, 2015

mikewest Nov 6, 2015

annevk Nov 6, 2015

mikewest commented Nov 6, 2015

annevk commented Nov 6, 2015

annevk commented Nov 6, 2015

annevk commented Nov 6, 2015

sc0ttbeardsley commented Nov 6, 2015

awebdeveloper commented Mar 28, 2016

awebdeveloper commented Mar 28, 2016

		@@ -20968,6 +20968,11 @@ interface <dfn>HTMLHyperlinkElementUtils</dfn> {

		</li>

		<li><p>If <var>subject</var>'s <a href="#linkTypes">link types</a> include the <code

Add a 'noopener' link attribute #290

Add a 'noopener' link attribute #290

Conversation

mikewest commented Oct 27, 2015

mikewest commented Oct 27, 2015

annevk commented Oct 28, 2015

mikewest commented Oct 28, 2015

annevk commented Oct 29, 2015

domenic commented Oct 29, 2015

mikewest commented Oct 29, 2015

mikewest commented Nov 5, 2015

annevk commented Nov 5, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikewest commented Nov 5, 2015

sc0ttbeardsley commented Nov 5, 2015

annevk commented Nov 5, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Nov 5, 2015

sc0ttbeardsley commented Nov 5, 2015

annevk commented Nov 6, 2015

mikewest commented Nov 6, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk commented Nov 6, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mikewest commented Nov 6, 2015

annevk commented Nov 6, 2015

annevk commented Nov 6, 2015

annevk commented Nov 6, 2015

sc0ttbeardsley commented Nov 6, 2015

awebdeveloper commented Mar 28, 2016

awebdeveloper commented Mar 28, 2016