Hacker News Reader

Comment by jordanthoms | Hacker News Reader

This makes me sad... I can remember being excited about this feature from the comics. It seems that case would have been handled by adding popup blocking for automatic popups like chrome has now, and keeping containment for ones which are triggered by clicking a link.

Maybe Chrome should just have a (hidden) option to apply the current blocking policy for automatically triggered popups to all popups instead, i.e. they show up in the address bar and you have to click the message to show them. How hard do you think it would be to write a patch for that do you think it'd have a chance of being accepted?

View on HN

With the caveat that I am an engineer and don't make UI decisions, I can guess for you some probabilities.

Patches that add hidden options are always rejected. Chrome has hidden options in about:flags but in principle they're all just hiding works in progress that will eventually be permanently on.

Patches that add options are rejected 99% of the time. Chrome has a general "no options" policy. (Here is where someone will want to comment about how that policy is dumb and is why they use Opera instead; I don't care, I'm just telling you the facts.)

Patches that permanently change the UI in the way you describe might be applied, if they're seen as strictly superior to the way things currently behave. I'm not exactly sure what you're proposing (your description seems to be describing how Chrome currently behaves? not exactly sure how constrained windows relate to that?) but your best bet is to write the patch first and then bring up a discussion of it on the development mailing list. (Writing the patch first prevents your discussion from being a discussion about vaporware.)

Sorry if I sound grumpy, I've just seen many feature proposals in my time and I'm hoping to help you not waste your time. :)

My understanding is: Chrome splits popups into two categories: ones triggered by anchor elements, and ones triggered by other JS. The ones triggered by anchor elements are assumed to be useful and are not blocked. The ones triggered by other JS are hidden and placed in the titlebar.

So the theory is that advertising popups would fall into the latter category, and functional ones into the former - but it seems in practice, sites which want to show popups actually just have them be created every time you click a link and don't bother with creating ones without clicks, since they are always blocked. So you still end up getting a lot of popups getting through the blocker.

My proposal is to eliminate distinction between the categories, and just block all popups. It's rare to come across a site which uses popups legitimately, and even in that case most of them are not triggering the popup on click so the popup is being blocked by the current policy anyway.

EDIT: Although, someone just pointed out a very common legitimate usage - Oauth / facebook login. Guess this is a tricky policy area.

That policy is dumb and that is why I use Opera instead!

He doesn't care, he's just telling you the facts.

In all seriousness though: Google does things their own way, and that's fine. But design policies (policies in general) tend to migrate between business domains.

Pointing out that you're personally not a fan of some particular policy (provided you do so politely and don't belabor the point) can be informative for incidental third parties as well as for the people currently writing the rules.

I know I for one appreciate it, for the same reason I appreciate Google's public programming style guides.

> Patches that add options are rejected 99% of the time.

Ah, yes, the "You're holding it wrong" mindset in action.

You don't need a hidden option or patch for that, there are several extensions that work well: https://chrome.google.com/webstore/search/popup%20blocker

I'd rather have a central, native, supported way to block popups, than trust some arbitrary third party JS code that has to run on every bloody page, and look at all my content.

I've tried many of them, and they of them cause major breakage on lots of sites.

chromium-dev@chromium.org would be an awesome place to ask that question.

Please don't. chromium-dev is about active development work, not about discussing features. chromium-discuss is the place you're looking for.

Reply on news.ycombinator.com