Open
Bug 1004916
Opened 11 years ago
Updated 2 years ago
Add UI for a "block all popups" non-default option for the popup blocker
Categories
(Firefox :: Settings UI, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: a_nut_in, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: parity-ie)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140421221237
Steps to reproduce:
On random sites, IE popup blocker works much better than FF - which is just plain ineffective
Actual results:
Case in point: http://songspk.name/bollywood-songs-.html
Try the same site in FF with popups disabled - and Windows 7 / IE 11 with Popup blocked and additional option of "block all popups"
FF still allows additional windows to be spawned if a link is clicked while with the above settings, IE works much better
This is also a potential drive - by - downloads issue for in experienced users
Expected results:
FF should have blocked all popups
Updated•10 years ago
|
Comment 1•10 years ago
|
||
So is this just asking for the additional "block all popups" option?
We have that in the core, with pretty fine-grained control over when popups are allowed, exactly. See the dom.popup_allowed_events preference. This bug sounds like it's just asking for UI for that, which would very much not be a core DOM issue.
I should note that chances are this option would also break things like the search result links on Yahoo search, since they open the page in a separate window from the search results.
Component: DOM → Preferences
Product: Core → Firefox
Summary: Popup Blocker Ineffective as compared to Internet Explorer on random sites → Add UI for a "block all popups" non-default option for the popup blocker
Comment 2•10 years ago
|
||
(In reply to Not doing reviews right now from comment #1)
> See the dom.popup_allowed_events preference.
Bug 964492 — sites can still get past an empty dom.popup_allowed_events preference.
> This bug sounds like it's just asking for UI for that, which would very much not
> be a core DOM issue.
I interpreted this report as Internet Explorer being more efficient at blocking pop-ups, right out of the box. I missed the “option of ‘block all popups’” buried in the Actual Results where it doesn't belong.
> I should note that chances are this option would also break things like the
> search result links on Yahoo search, since they open the page in a separate
> window from the search results.
user_pref("dom.popup_allowed_events", "");
user_pref("browser.link.open_newwindow", 1);
user_pref("browser.link.open_newwindow.restriction", 0);
That still leaves the following, which can be worked around by adding the site to the pop-up blocker exceptions.
Bug 918780 — it also blocks the file picker for uploads, with no way to open it.
Alternatively, the requested feature is provided by add-ons like the following:
https://addons.mozilla.org/firefox/addon/strict-pop-up-blocker/
Whiteboard: [parity-ie] → [parity-ie] [parity-seamonkey]
Updated•10 years ago
|
Whiteboard: [parity-ie] [parity-seamonkey] → [parity-ie]
Comment 3•10 years ago
|
||
> Bug 964492 — sites can still get past an empty dom.popup_allowed_events preference.
Can't reproduce. Can you?
> Bug 918780 — it also blocks the file picker for uploads, with no way to open it.
Yeah, that's a problem. Hard to have it both ways, because sites can abuse the filepicker popup just like they can window popups.
Depends on: 1266660
No longer depends on: 1266660
Comment 4•7 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-ie
Whiteboard: [parity-ie]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•