5 ms·

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.

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

by evmar 13y ago

dsl 13y ago

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

ryguytilidie 13y ago
He doesn't care, he's just telling you the facts.
- yew 13y 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 13y 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 13y ago

> Patches that add options are rejected 99% of the time. Ah, yes, the "You're holding it wrong" mindset in action.