Live data from Hacker News

About rel=noopener (2016)

mathiasbynens.github.io

11–20 of 48 posts

Re: About rel=noopener (2016)

#11
My totally unmeasured hunch is that there is a downside to using noopener: it could make the new page that is being opened take slightly longer, since it now needs to spool up another process/thread/sandbox/whatever instead of piggy backing off the existing page's.

More about the performance "benefit" here: https://jakearchibald.com/2016/performance-benefits-of-rel-n...

Re: About rel=noopener (2016)

#12
post #5

Earlier quoted context omitted.

Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.

I remember this very thing being discussed years ago. Since this is still a problem, I'd say the web needs a way to gracefully migrate away from bad decisions like window.opener being available across origins. Should we not decide that cross-origin window.opener is now deprecated, show big fat warnings on the developer console when it's used, and remove it in a year or two? I'd like an option to completely turn it of…

in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.

Re: About rel=noopener (2016)

#13
post #5
post #3

Shouldn't this behavior be explicitly enabled, defaulting to disallowing it? Or do I need to tag all my links with a long series of "Don't allow this crazy thing", "Or that other thing", etc.

Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.

According to https://jakearchibald.com/2016/performance-benefits-of-rel-n... edge doesn't set window.opener for blank links so I'd assume it's not being used that much. I mean, it's Microsoft, they usually go out of their way to be backwards compatible.

Re: About rel=noopener (2016)

#14

Earlier quoted context omitted.

I remember this very thing being discussed years ago. Since this is still a problem, I'd say the web needs a way to gracefully migrate away from bad decisions like window.opener being available across origins. Should we not decide that cross-origin window.opener is now deprecated, show big fat warnings on the developer console when it's used, and remove it in a year or two? I'd like an option to completely turn it of…

in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.

Internet Explorer tried to maintain multiple rendering engines. Every version from IE5 to IE11 (if you open the debug console you can switch rendering modes) And now they have Edge. It never took off.

I suspect the cost of breaking web compatibility intentionally to accomplish this goal would kill a browser, as authentication, payment, and many other things would suddenly break.

Re: About rel=noopener (2016)

#15
post #5
post #3

Shouldn't this behavior be explicitly enabled, defaulting to disallowing it? Or do I need to tag all my links with a long series of "Don't allow this crazy thing", "Or that other thing", etc.

Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.

Just warn them that at some point in time the feature will cease to work. I see these warnings in the console all the time for broken SSL CAs and deprecated DOM APIs.

Re: About rel=noopener (2016)

#16

Earlier quoted context omitted.

I remember this very thing being discussed years ago. Since this is still a problem, I'd say the web needs a way to gracefully migrate away from bad decisions like window.opener being available across origins. Should we not decide that cross-origin window.opener is now deprecated, show big fat warnings on the developer console when it's used, and remove it in a year or two? I'd like an option to completely turn it of…

in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.

HTML 2.0 was published in 1995.

I doubt this behaviour comes purely under html anyway as its only usable from the javascript environment.

More likely is a content security policy... oh looke there: https://w3c.github.io/webappsec-csp/#directive-disown-opener

Re: About rel=noopener (2016)

#17
post #5
post #3

Shouldn't this behavior be explicitly enabled, defaulting to disallowing it? Or do I need to tag all my links with a long series of "Don't allow this crazy thing", "Or that other thing", etc.

Lots of existing apps, including some that handle payment information, rely on window.opener to provide a seamless experience when using pop-ups or iframes from a different domain. In an ideal world, these apps would have been rewritten a long time ago using more modern techniques. In reality, browsers bend over backwards to maintain backward compatibility with existing apps.

Seems like the simple solution would be for those apps to include something like “rel=yesopener” on the link to the payment provider, as a way to explicitly opt into the functionality.

Browsers deprecate security related features all the time. See SSL, HSTS [EDIT: HPKP*], etc.

At the very least, browsers could remain backward compatible but mark the URI as “Insecure” in the address bar if the link could result in tab hijacking. Although on second thought, that would be challenging because it would require parsing the source of all links.

Re: About rel=noopener (2016)

#18

Earlier quoted context omitted.

in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.

HTML 2.0 was published in 1995. I doubt this behaviour comes purely under html anyway as its only usable from the javascript environment. More likely is a content security policy... oh looke there: https://w3c.github.io/webappsec-csp/#directive-disown-opener

I'm aware of that - the existing HTML versions have been pretty much incremental though. XHTML was a breaking change but more for syntactical reasons. By a "2.x" version I mean a fresh rewrite with no requirements for parity with previous versions, so the lessons of the current engine can be applied in a clean-slate environment.

Re: About rel=noopener (2016)

#19
post #14

Earlier quoted context omitted.

in semantic versioning terms, we need a "2.x" of the HTML API. We'd need to break backwards compatibility across the board and have sites opt in to use v2 using some kind of flag. The benefits would be massive but it would also require browsers to essentially have 2 different engines to support both legacy and v2 websites.

Internet Explorer tried to maintain multiple rendering engines. Every version from IE5 to IE11 (if you open the debug console you can switch rendering modes) And now they have Edge. It never took off. I suspect the cost of breaking web compatibility intentionally to accomplish this goal would kill a browser, as authentication, payment, and many other things would suddenly break.

this is why I say it would have to be opt-in through something like a header or tag on the page in question (although I don't think doctype would work well for this). Existing sites would use the current engine and sites that explicitly stated they were for the new engine would be handled differently.
Post reply on HN