5 ms·

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 au

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?

randall 14y ago
chromium-dev@chromium.org would be an awesome place to ask that question.
- groby_b 14y ago
  Please don't. chromium-dev is about active development work, not about discussing features. chromium-discuss is the place you're looking for.
evmar 14y ago
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. :)
- dsl 14y ago
  That policy is dumb and that is why I use Opera instead!
  - ryguytilidie 14y ago
    He doesn't care, he's just telling you the facts.
    - yew 14y ago
      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.
- jordanthoms 14y ago
  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.
- derleth 14y ago
  > Patches that add options are rejected 99% of the time. Ah, yes, the "You're holding it wrong" mindset in action.
modeless 14y ago
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 https://chrome.google.com/webstore/search/popup%20blocker
- coldtea 14y ago
  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.
- jordanthoms 14y ago
  I've tried many of them, and they of them cause major breakage on lots of sites.

randall 14y ago

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

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

evmar 14y ago

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. :)

dsl 14y ago
That policy is dumb and that is why I use Opera instead!
- ryguytilidie 14y ago
  He doesn't care, he's just telling you the facts.
  - yew 14y ago
    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.
jordanthoms 14y ago
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.
derleth 14y ago
> Patches that add options are rejected 99% of the time. Ah, yes, the "You're holding it wrong" mindset in action.

modeless 14y ago

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 https://chrome.google.com/webstore/search/popup%20blocker

coldtea 14y ago
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.
jordanthoms 14y ago
I've tried many of them, and they of them cause major breakage on lots of sites.