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.
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?
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.
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.
Chrome does block popups and doesn't have problems doing so, it's just that what's described by the OP and the link is a different way of displaying popups. It was apparently confusing to the reviewer and never did ship.
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.
My main annoyance is that a lot of sites now (knowing that if they create a popup the old way it'll be blocked), now just wait till you click or mouse over something and create the popup then, which chrome then allows (it's not blocked at all). So this means the majority of advertising pop ups on the web are actually not blocked by 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).
What you're referring to is not just MDI. TDI is usually considered a subset of MDI, so tabbed browsers are MDI. Ditto for emacs/vim are MDI, even though they're text, and screen/tmux are MDI wrappers for other programs. Do you have a problem with those too?
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.
Tabs and the other things you describe are good only as long as you can split stuff out into its own window. Tabbed browsers I've used do this, as does screen. Don't know about the others, as I haven't used them.
If tabs were held captive within their original window forever, I'd find them terribly annoying.
I am not necessarily taking a stance for or against New Compose here, but I am taking the stance that your advice is somewhat near-sighted.
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.
popups triggered directly by a click are allowed, because otherwise you'd break e.g. Facebook login, to pick a major example. Basically every browser does this. Quite a few are probably undesirable still, but otherwise people simply claim the browser is broken for their normal site X and abandon it entirely for a browser that doesn't break site X.
You don't have it? It works for me. I'll get a "Pop-up notification blocked" message right next to the star in the address bar. I can click on it and continue to ignore pop-ups, or choose to open them if I need to see them.
Pretty much exactly the feature described in the comic. Maybe you have it turned off somehow.
This seems like a great feature, and sadly missing from Chrome.
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).