Closed Bug 132031 Opened 22 years ago Closed 22 years ago

Need UI for new dom.disable_open_click_delay pref

Categories

(Core :: Security: CAPS, defect)

Product:
Core
Component:
Security: CAPS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
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.
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.)
Open unrequested windows where the Webmaster was:
[/] annoying
[/] annoying and smart

... Um, yeah. Just merge 'em.
Hardware: PC → All
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
I'm redoing the panel anyways, so I will include this into my changes.
Over to Doron - thanks for taking care of this.
Assignee: mstoltz → doronr
Once 117707 is in (if I can find a reviewer soon), I will do this.
Depends on: 117707
*** Bug 133871 has been marked as a duplicate of this bug. ***
*** Bug 137972 has been marked as a duplicate of this bug. ***
*** Bug 139070 has been marked as a duplicate of this bug. ***
*** Bug 140089 has been marked as a duplicate of this bug. ***
*** Bug 140240 has been marked as a duplicate of this bug. ***
*** Bug 140755 has been marked as a duplicate of this bug. ***
*** Bug 142675 has been marked as a duplicate of this bug. ***
*** Bug 138509 has been marked as a duplicate of this bug. ***
*** Bug 143076 has been marked as a duplicate of this bug. ***
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
*** Bug 143750 has been marked as a duplicate of this bug. ***
*** Bug 153606 has been marked as a duplicate of this bug. ***
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.
Keywords: mozilla1.1
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.
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: 22 years ago
Resolution: --- → WONTFIX
Verified WONTFIX.
Status: RESOLVED → VERIFIED
Blocks: popups
You need to log in before you can comment on or make changes to this bug.