When we sent the very first Chrome out to reviewers, one reviewer sent back a draft of a review that said Chrome seemed like a nice browser but it had the strange additional feature of popping up ads inside the pages as you browsed.
The reviewer was so accustomed to their existing browser simply blocking pop-ups that it didn't occur to them that the pop-ups were caused by the pages they were visiting, and instead thought it was some Chrome monetization strategy!
Because of this, the feature was scrapped at the last second. There is still some "constrained window" code left over in Chrome that is still used for e.g. HTTP auth prompts. Because the ports came later, I seem to recall we didn't bother with implementing all the draggy window management stuff on Linux and instead centered a dialog over the page content without the window manager controls.
You can search on http://cs.chromium.org for [constrained_window] to see some of the remaining code.
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?
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. :)
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.
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.
Ah, yes, the "You're holding it wrong" mindset in action.
Why didn't Chrome simply block the popups as well? (NB: I switched back to Firefox a year ago, so I don't know if popups are still a problem in Chrome.)
I, for one, detest the new trend of every website trying to invent its own windowing manager. "New Compose" is the perfect example of this. I don't want every website creating its own internal windows that I can't move, resize, or control with the same power that my windowing manager (whether via X11, Aqua, or whatever Windows uses) gives me.
For me, if a popup is at all useful, I'd rather have it pop up in a separate window (and then I can move it back into a tab easily if I like it.
And if it's not useful, just kill it from the onset. (One of my extensions - probably AdBlock - seems to do a good job of determining this, for me).
The problem at hand is not MDI but broken MDI that implements a different interface or context than the top-level desktop. That's a problem regardless of whether the model is SDI, TDI, or other MDI. You seem to hate the overlapping-window "other MDI" model in any context, which is fine but slightly orthogonal.
If tabs were held captive within their original window forever, I'd find them terribly annoying.
I'm not a big fan, no.
return FALSE; // 96% accurate
Here's a little experiment that demonstrates why: name "Revert to Previous Behavior" modes in any major webapp that has been around more than 6 months after the new behavior was rolled out to everyone.
The feature went through several iterations. Originally, popups were just shown with their requested size anywhere within the browser window. The idea was that a page could only damage itself by opening popups and not interfere with your window manager state.
This was deemed ineffective (sites knowingly do stuff to themselves like this all the time - e.g. overlay divs), so we auto-positioned them at the bottom right and hoped you figure out that their titlebars were stacked down there and would drag them up.
Then we made them detach immediately when you clicked them.
Then we got the feedback evmar mentions and we just did the boring thing. Personally I find it less discoverable now (and am constantly missing popups) but non-user-gesture generated popups seem relatively rare on the web these days compared to more annoying stuff.
As long as it doesn't contain any anchors.
Pretty much exactly the feature described in the comic. Maybe you have it turned off somehow.
I have thought of two types of insidious activities on sites today, the onclick popup and the confirm on close.
The onclick popup can be managed (to a small extent) in Chrome by holding the CTRL key and clicking when you have a sense a popup is coming. It doesn't cover all of them, but if you're familiar with a site's actions, you might catch 70% or more of them.
I'm not sure what creates the confirm on close, but I see it on sites that auto play video advertisements (among others). Once you try and close the window/tab - Chrome displays a prompt - requiring you to close the prompt, and then close the tab. Annoying.
I thought of one simple idea in Chrome - have a key combination (perhaps CTRL+SHIFT) that we can hold down while clicking on a link or possible popup, that will (a) open the link in a new tab and (b) NOT load the page or any elements. It simply presents an empty page with the url that we could copy or a tab we can close.
This would add a measure of control and hopefully doesn't break anything.
each tab can have one popup overlaying it. as annoying for advertising, and useless for sites that depends on popups as they usually require more than one, or require one to stay open when you keep working on the tab (which is inaccessible until you close the popup)
why not allow me to open as a new tab, i will never understand.
1. if the site requires pop-ups to function, then wouldn't it be handy to have it in front of you? Few apps run this model anymore, but it used to be very prevalent.
2. to highlight the sites that use pop-ups in an underhanded way; by forcing them onto the tab that caused them, hopefully you'd realize the source of the problem. then, complain or quit using that site, indirectly discouraging the use of pop-ups. (although according to a guy above, users actually blamed the ads on Chrome instead).