Live data from Hacker News

About rel=noopener

mathiasbynens.github.io

51–60 of 115 posts

Re: About rel=noopener

#51

Earlier quoted context omitted.

Probably there are, but they're hardly likely to rely on it working cross-origin, and if they are they almost deserve to have it broken...

Not sure but I would think anything that use a pop up to login using social media account would like to get an event back when successfully logged in?

Social media networks are well placed to get their little embedded code snippets updated across the web. And chances are, these links are being generated by a cross-origin javascript library anyway. If you wanted to be very generous, browsers could auto-whitelist origins of every javascript library loaded in the page.

In any remaining cases, there should still be some method to white-list the current behavior, e.g. rel=allowopener.

Re: About rel=noopener

#52
post #47

Earlier quoted context omitted.

Good call! I guess i haven't seen any of those. But i've seen some internal web based systems that relied too heavily on popup windows and started breaking when tabbed browsing became a thing and brosers started blocking popup windows by default, so i don't doubt that there are probably systems out there relying on this weird behavior of target=_blank. For those systems, though, i'd imagine most of them would have th…

There are more than 1 billion websites. If just 0.1% of sites use target=_blank like that, you'd be breaking a million sites with your change. You can't use arguments like "I haven't seen any of those" or it "seems like a sensible idea" when making decisions like this.

The "I haven't seen any of those" was just as a comment on why i couldn't think of possible uses for this target=_blank behavior, not a justification for the proposed change (what a lame justification that would be! :)

That being said, i don't see how the proposal of browsers blocking popup windows from redirecting the parent window (if it's cross-origin) by default is any different from, for instance, them blocking popup windows from opening unless it was a user action that triggered them, which all browsers started doing by default quite some time ago. Could you elaborate on why this wouldn't be a sensible solution?

Re: About rel=noopener

#53
post #47

Earlier quoted context omitted.

Good call! I guess i haven't seen any of those. But i've seen some internal web based systems that relied too heavily on popup windows and started breaking when tabbed browsing became a thing and brosers started blocking popup windows by default, so i don't doubt that there are probably systems out there relying on this weird behavior of target=_blank. For those systems, though, i'd imagine most of them would have th…

There are more than 1 billion websites. If just 0.1% of sites use target=_blank like that, you'd be breaking a million sites with your change. You can't use arguments like "I haven't seen any of those" or it "seems like a sensible idea" when making decisions like this.

Lots of websites used to use Java applets, but browsers decided they're not worth the security risk and made users jump through more and more hoops to start embedded Java.

Re: About rel=noopener

#55
In the right circumstances, which as far as I can tell are when crossing between security zones, Internet Explorer and Edge already seem to block this. I've never been able to pin down exactly what's happening, or to get Google login to work on our intranet sites with IE as a result.

Re: About rel=noopener

#56
post #47

Earlier quoted context omitted.

There are more than 1 billion websites. If just 0.1% of sites use target=_blank like that, you'd be breaking a million sites with your change. You can't use arguments like "I haven't seen any of those" or it "seems like a sensible idea" when making decisions like this.

The "I haven't seen any of those" was just as a comment on why i couldn't think of possible uses for this target=_blank behavior, not a justification for the proposed change (what a lame justification that would be! :) That being said, i don't see how the proposal of browsers blocking popup windows from redirecting the parent window (if it's cross-origin) by default is any different from, for instance, them blocking…

It does seem like a sensible solution, but the web isn't exactly a sensible place. People use terribly-written web sites for all sorts of things that are important to them in their life. Changes that potentially break these sites shouldn't be taken lightly.

Re: About rel=noopener

#57
post #12

What is the correct way to force a link to open in a new tab, then? Unfortunately "let the user decide" is not the best answer if you want to link to something like "terms and conditions" in the middle of a sign up flow or something. If the user doesn't know how to open it in a new tab on their own, this can be extremely frustrating I'd imagine.

> What is the correct way to force a link to open in a new tab, then?

What is the correct way to stalk, hunt, kill, stuff and mount the user?

Answer: there is no correct way to do something which is fundamentally incorrect.

> Unfortunately "let the user decide" is not the best answer if you want to link to something like "terms and conditions" in the middle of a sign up flow or something. If the user doesn't know how to open it in a new tab on their own, this can be extremely frustrating I'd imagine.

Abusing my browser is extremely frustrating for me. If I want to open a link (a link, see, not some horrid piece of JavaScript) in a different tab, I middle-click and get on with life. You don't need to do that for me, any more than you need to offer me a typing widget when I have a perfectly functional keyboard, or fake a link when I have a browser perfectly capable of understand the tag, or check my (correct) email address with an incorrect regular expression.

Please don't break the Internet.

Re: About rel=noopener

#59
post #57
post #12

What is the correct way to force a link to open in a new tab, then? Unfortunately "let the user decide" is not the best answer if you want to link to something like "terms and conditions" in the middle of a sign up flow or something. If the user doesn't know how to open it in a new tab on their own, this can be extremely frustrating I'd imagine.

> What is the correct way to force a link to open in a new tab, then? What is the correct way to stalk, hunt, kill, stuff and mount the user? Answer: there is no correct way to do something which is fundamentally incorrect. > Unfortunately "let the user decide" is not the best answer if you want to link to something like "terms and conditions" in the middle of a sign up flow or something. If the user doesn't know how…

On the other hand, I almost never want to have a link open in the same tab. There's nothing more frustrating than being halfway down a page, forget to hold down ctrl when I click on a link, and have all of my state on the old page blown away and replaced with the new one.

Probably this is a result of the internet already being broken, since the worst of it is in infite-scrolling type things where my confidence that I can get back to where I was originally after going back is very, very low.

Post reply on HN