Hacker Newsnew | comments | show | ask | jobs | submit login
What happened to Chrome's popup confinement feature? (google.com)
135 points by jordanthoms 756 days ago | 53 comments



(I used to work on Chrome.)

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.

-----


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.

-----


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.

-----


> The reviewer was so accustomed to their existing browser simply blocking pop-ups

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

-----


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.

-----


Unfortunately, that wasn't my experience. I even tried the Better Popup Blocker extension, and I would still get them (especially from Netflix).

-----


Are those scammy popups actually netflix, or people using the affiliate program?

-----


It's actually terrible about it, an addon is required and even those aren't fool-proof.

-----


I find it hard to believe that Google made a major feature decision based on one person's feedback.

-----


It was Larry Page.

-----


BTW you can see the remnants of the code that supported this feature for popups still in use for things like HTTP Basic Auth dialogs: http://www.pagetutor.com/keeper/http_authentication/index.ht...

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.

-----


So my real gripe is with javascript popups triggered on click - they aren't blocked (which is reasonable since that can break apps), which is why the idea of displaying it only within the tab and not interrupting the user was brilliant. Except chrome doesn't do that anymore! (or maybe it never actually did, I can't remember).

"There's no concept of a drive-by pop-up in Chrome. JavaScript has no way to force a pop-up into your world. Pop-ups are scoped to the tab they came from -- and confined there. If it's something you want, though -- just drag it out and it'll be promoted to its own window."

-----


Triggered on click is fine if it is attached to a link element. Triggered on click attached to the document or a container div is the problem.

-----


You can just style an anchor to be said container div.

As long as it doesn't contain any anchors.

-----


I guess there would need to be some heuristics as to what is and isn't allowed.

-----


I'd rather block them.

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

-----


MDI is an abomination on the desktop, and it's no less so in the browser.

-----


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.

-----


Do you have a problem with those too?

I'm not a big fan, no.

-----


To nitpick: I've never considered TDI to be a subset of MDI, but rather MDI a superset of SDI and TDI. MDI implies a level of control and configuration not remotely possible with the other two.

-----


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.

-----


Chrome itself is a multiple document interface. So is every other tabbed interface. So is every other program that allows you to interface with multiple documents.

-----


That's nitpicking, we all know the term MDI refers to MS Windows style Window manager within a Window.

-----


No it doesn't.

http://en.wikipedia.org/wiki/Multiple_document_interface

-----


How should the browser determine if the popup is useful or not?

-----


  int isPopupUseful()
  {
    return FALSE; // 96% accurate
  }

-----


I'd say 96% is being a tad conservative.

-----


Couldn't they use something similar to a spam filter?

-----


They appear to block all popups except those caused by a direct click by the user. I think that's why some websites spam popup windows when you make your first click.

-----


You can solve the "New Compose" problem (just freaking revert back to the previous behavior, GMail), without re-enabling the abomination that was browser popups.

-----


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.

-----


Can someone explain why some websites I visit still manage to make popups appear ?

-----


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.

-----


The comic describes allowing popups, but confining them to within the tab, then allowing you to drag them out to their own window.

-----


Try the links here: http://www.popuptest.com/goodpopups.html

-----


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.

-----


Just to add to this - the javascript event used to capture leaving the open page seems to be: window.onbeforeunload - it would be great if Chrome was able to disable that function entirely, but it doesn't seems possible.

-----


It's there on android and i absolutely hate it!

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.

-----


Perhaps it's 2-fold:

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

-----


This is obviously lies. I don't recall it existing.

-----


It's such a good idea though, I wish they would implement it!

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: