Getting rid of popup windows for good
rq at akl.lt
Tue Aug 26 18:06:53 UTC 2014
2014.08.26 00:29, Gijs Kruitbosch wrote:
> On 24/08/2014 18:30, Rimas Kudelis wrote:
>> 1. the web has evolved, and legitimate use of real pop-ups seems quite
>> rare nowadays,
> You're using a different web from me, and many other users, clearly. I
> see very few if any unwanted popups, with my browser often open for
> multiple days and 0 unexpected windows appearing and/or remaining
I'm not saying I get an awful lot of them, but I do get some, and
usually, they are unwanted.
> I'm sure there are places where you never see "real" popups, but e.g.
> GMail provides primary UI to open compose/chat windows in their own
> (popup) windows, and I'm sure there are many similar examples. Then
> there are all the wifi gateway sites that open "you're logged in"
> popups, and so on.
Don't know about "your" GMail, but "mine" (although I almost never use
it) opens Compose message UI in a <div>, and offhand I couldn't find a
button to open it in a real pop-up. Chat windows open in a <div> as
well, but yes, they have a button which pops them up in a real window.
Also see below.
> Without hard data, it's difficult to be sure, but I think this first
> claim ('legitimate use of real pop-ups seems quite rare nowadays')
> does not reflect the broader web, and that we therefore shouldn't make
> what you suggest the default.
There were 4 more claims. One of them was that whitelisting a website
where you *want* pop-ups is already easy. If what we have is not easy
enough, then maybe it should be made even easier. What's currently hard
(almost impossible) is to block all pop-ups where you don't want them
(e.g. in The Pirate Bay, see my other reply).
(Note to Gavin: the pop-under code from TPB is available at
I believe that the ability of a blacklisted website to open pop-ups in
response to certain JS events is certainly a bug (I took time to
blacklist it, why is that preference not being favored?). If we don't
want to block all pop-ups by default, than perhaps at least this bug
should be fixed. However, in that case, our permissions UI should also
be updated, because this setting is then effectively not binary (allow
[all]/block [some] pop-ups), but trinary (allow all/allow some/block all
> That doesn't mean not fixing e.g. bug 918780 so that users who do
> change these prefs themselves can do that, but I don't know how highly
> that should be prioritized.
I find it particularly weird that a file chooser window of <input
type="file" /> is considered a pop-up opened by the website I'm in. The
window is created by chrome, the handler is run by chrome. The most that
the website can do is trigger the Click event of that element. Thus I
think bug 918780 should definitely be fixed. And it would absolutely
have to be fixed if should we decide to go my way.
More information about the firefox-dev