Closed
Bug 132031
Opened 23 years ago
Closed 23 years ago
Need UI for new dom.disable_open_click_delay pref
Categories
(Core :: Security: CAPS, defect)
Core
Security: CAPS
Tracking
()
VERIFIED
WONTFIX
People
(Reporter: rginda, Assigned: doronr)
References
(Blocks 1 open bug)
Details
Bug 126224 introduced a new pref called "dom.disable_open_click_delay" which disables window.open when called more than X milliseconds after a mouse click. When used in conjunction with "dom.disable_window_during_load", this blocks most unwanted popups. "dom.disable_window_during_load" is still needed because pages often begin loading soon after a mouse click, and their top level script would still be allowed to open a new window if only "dom.disable_open_click_delay" were used. It has been suggested that the "Allow scripts to open unrequested windows" UI element actually control both of these prefs. Perphaps setting "dom.disable_open_click_delay" to a default value of one second when enabled, and deleting (or set to 0) when disabled. Users with existing profiles with this pref enabled would see "Allow scripts to open unrequested windows" as checked, when they actually only hav half of the pref. That's not that big of a deal, I suppose. It is also possible that a user will find a reason to use one, but not the other pref, or tweak the value of "dom.disable_open_click_delay" to a value other than the default. For example, I recall a bug where "dom.disable_open_during_load" caused a MS webmail service to not work properly. A user could use only "dom.disable_open_click_delay", with a very small value, to block most popups without affecting their webmail.
Comment 1•23 years ago
|
||
ALL unrequested windows, of any kind, should be controlled by the existing UI. Otherwise it doesn't make any sense. Nor does it make sense to change the UI text - this would only unnecessarily confuse people. If there really *IS* a need for more fine-grained control (Is there?) then perhaps it could be broken down into "All" and "Some" - Some bringing up a listing of the various components that could be checked / unchecked. However, I really think that this is unnecessarily confusing and that an all/nothing would be sufficient in the UI. (Advanced users could change the prefs.js file directly if they wanted fine-grained control.)
Comment 2•23 years ago
|
||
Open unrequested windows where the Webmaster was: [/] annoying [/] annoying and smart ... Um, yeah. Just merge 'em.
Hardware: PC → All
Comment 3•23 years ago
|
||
Per prefs ownership model, prefs of this nature are now being handled by the Security: CAPS component. Reassigning as such.
Assignee: sgehani → mstoltz
Component: Preferences → Security: CAPS
QA Contact: sairuh → bsharma
Assignee | ||
Comment 4•23 years ago
|
||
I'm redoing the panel anyways, so I will include this into my changes.
Assignee | ||
Comment 6•23 years ago
|
||
Once 117707 is in (if I can find a reviewer soon), I will do this.
Depends on: 117707
Comment 16•23 years ago
|
||
The delay fix doesn't seem necessary to me. The javascript execution path is either initiated from Mozilla (the page is loaded, so execute "onload". the page is loading so execute js as it is parsed, a Mozilla execution path called setTimeout() and the timeout has occured, etc) or by the user (an actual mouse click triggered is being handled by a handler, a user path has called setTimeout(), etc). In the case of the page at http://ad.doubleclick.net/adi/N339.nytimes.com/B922384;sz=720x300;ord=2002.04.23.15.36.39? it is just a simple onload that pops the window under. This solution seems too complex
Comment 19•23 years ago
|
||
Let me also cast my vote for keeping the UI *as is*. See Chris Casciano's comments on bug 126224: http://bugzilla.mozilla.org/show_bug.cgi?id=126224#c32 "Your average web surfer is dumb to the ways of the web developer. They don't know the difference between a window.open() in a body onload, an image onload, one that's just sitting out there to be executed sans event..." Regardless of whether *this* user is "dumb" or not, the point is well-taken: having the UI shut down *all* popups from a single checkbox is entirely reasonable. It should also be noted that future implementations of HTML or any successor language will likely have annoyances that cause popups or popunders; should Moz wait for the standards committees to announce them and proliferate checkboxes as we go? No.
Updated•23 years ago
|
Keywords: mozilla1.1
Comment 20•23 years ago
|
||
I agree with whoever said this first, disabling all popups via one UI pref setting would be much easier for the average user. It would also avoid all the dups of this bug and Bug #126224.
Comment 21•23 years ago
|
||
per comments by rginda in bug 126224 marking wontfix. This solution was temporary and incremental, and exposing a UI for it would defeat the purpose of having a UI for "disabling unrequested windows" bug 126224 will be the bug for revamping the current pop-up controlling mechanisms. The goal should be to create a list of "requested" possibilities and allow pop-ups only in those situations. Finding more and more "unrequested" ways to open a window will just require developers to work endlessly to stop each of them. The suggestion has even been made to back this pref out... bug 126224 comment 67 That would be a different bug
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•