Stop sites from opening popup or popunder windows, even in response to clicks




7 years ago
12 days ago


(Reporter: Kevin Brosnan, Unassigned)


(Depends on: 1 bug, Blocks: 2 bugs)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [Advo])


(1 attachment)



7 years ago
Sites can use the click or mouseup event to launch an advertising window. This is a known issue and bug 212163 covers onclick. Limi talked about revisiting this issue in the papercuts talk. If onclick is removed we should look at the rest of the values of dom.popup_allowed_events so that ad networks not just switch to a different event.

Currently dom.popup_allowed_events allows popups for change, click, dblclick, mouseup, reset, and submit.
Blocks: 565512

Comment 1

7 years ago
Disallowing onclick would break large swaths of the web.  On one hand, more sites use it for user-hostile advertising than for useful functionality; it has caused me to be afraid of clicking on anything while reading articles on sites I don't trust.  On the other hand, we generally want to optimize for friendly web apps; unfriendly sites are best avoided.

If we make this aggressive change, I suppose we will allow sites to open new windows only if:

* The user has set a site-pref, whitelisting the site for opening new windows.
* The user has promoted the site to "App tab" status.
* The user holds shift and clicks the page (cf bug 55696).
* The user clicks the existing "pop up holding area" and asks Firefox to open the blocked window.

Would we also have to disable <a target=_blank>, making it open in the same tab, so advertisers can't make the entire page be an <a target=_blank> that points to an advertisement?

Another possibility is to open new windows "inside" the tab, so that closing the tab also closes the extra window.  This is similar to our plan for alert()s.  Popup windows then become equivalent to "DHTML popups" in terms of user experience: pretty annoying, but at least you can leave the page at any time.  (Note bug 242237 which asks for ways to kill "DHTML popups".)

Yet another possibility is to attack only pop*unders*.  I think bug 502824 has a solution that would turn them into popups and not break much of anything. (Popunders are more problematic than popups because you often can't tell where they are coming from.)
Depends on: 502824

Comment 2

7 years ago
For <a target=_blank>, see also bug 565621.


7 years ago
Blocks: 565621


7 years ago
No longer blocks: 565621
Depends on: 565621


7 years ago
Summary: Stop sites from opening popup or popunder windows → Stop sites from opening popup or popunder windows, even in response to clicks


7 years ago
Blocks: 176958

Comment 3

7 years ago
There's an old wontfix bug on this topic, bug 212163.  But the web has changed since then.

Comment 4

7 years ago
A blacklist would also help a lot, see bug 202394.

Comment 5

7 years ago
About pop-unders: I wonder if there is any way to make them open in a new background tab next to the tab that opened it, and associated with the opening tab in Tab Candy.


7 years ago
Duplicate of this bug: 593652
I think bug 596359 is a reasonable approach to mitigating a lot of the unwanted popups by heuristically checking where the open call came from.
Depends on: 596359

Comment 8

7 years ago
One suggestion mentioned on IRC was to only allow App Tabs to do this by default.
Duplicate of this bug: 660308


5 years ago
Whiteboard: [Advo]
See Also: → bug 667337

Comment 10

3 years ago
Created attachment 8476809 [details]
The code that opens a popunder on The Pirate Bay

Bug 212163 has been wontfixed 11 years ago, but I believe the situation has changed a lot since then:

1. with AJAX and stuff, legitimate use of popups is probably quite rare nowadays.
2. on the other hand, websites, which use popups for advertising, have over the years adjusted to the way browsers block this functionality, and are using shady tactics of e.g. globally catching onclick basically anywhere in the page to open their popups or even popunders (that's what this and many other bugs are about).
3. not based on studies, but I would guess that most users usually interact with just a few websites at most, which use popups for legitimate reasons nowadays (e.g. corporate intranet, some government website, MAYBE webmail and let's say a few others).
4. whitelisting popups on any website is an easy one-time task. We have a nice UI (infobar and an icon in the address bar) for that.
5. with our current default setting, even blacklisted websites can still open pop-ups when using the right handler. This is ridiculous and exactly the contrary of the user being in control.

With all these points in mind, I would suggest that the decision in bug 212163 should be revisited. Can I reopen it?

BTW, I wonder if it's by design that with an empty dom.popup_allowed_events, even file chooser windows triggered by clicking <input type="file"> are blocked. That doesn't sound logical. Oh, apparently, it's bug 918780.


3 years ago
Depends on: 918780


2 years ago
Duplicate of this bug: 1178495
You need to log in before you can comment on or make changes to this bug.