Closed
Bug 29346
Opened 25 years ago
Closed 24 years ago
Prevent repeating pop-up windows
Categories
(Core :: Security, enhancement, P3)
Core
Security
Tracking
()
VERIFIED
FIXED
Future
People
(Reporter: jruderman, Assigned: security-bugs)
References
(Blocks 1 open bug, )
Details
(Keywords: helpwanted)
Since netscape has been established as the leading porn browser (because of its
handy "close all" feature, which is now called "quit"), it should also be set
up to easily disallow a porn site from opening lots of new windows, each of
which has javascript to open more windows (on open and/or on close events), etc.
(Note: if that didn't sound like a legitamate request because of the porn, note
that a buggy or malicious site might actually be _impossible to exit_ because
it kept re-opening itself with copies, or might get eat up all of the
computer's memory and bandwidth by having each window open two new copies)
Suggested solution: give each site an allowance of two pop-up windows. If a
site tries to exceed this limit, or if a window that was created by javascript
attempts to create a new window, bring up a choice box "open; always open;
don't open; disable javascript". I'm sure this isn't the best solution, so
please suggest others and/or options for this one. (The last option is in case
a site loops until the user allows the window to open.)
URL coming. Sorry in advanced for being too lazy find or make a non-porn site.
Don't click on it if your browser doesn't like opening and closing lots of
windows rapidly, if you don't like looking at porn, or if your parents won't
take "I was helping to alpha-test a cool open source browser" as an excuse for
having porn pop up on your screen where your little brother might see it.
http://lust-lake.porncity.net/gimmea404error
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think I have a better solution. In addition to offering a security setting
for disabling script, how about allowing a user to enable/disable/ or require a
prompt for the open() method?
I second doh_woohoo's idea. However, let us assume that one DID was to see a
new pop-up window and by force of habit, one clicked the "No, I don't want a
new window to open" button. Perhaps the browser could show a list of links at
the bottom of the page (in the style of footnotes) to allow users to open these
windows manually?
Comment 5•25 years ago
|
||
I don't know about all the fancy suggestions on how to od this. Every person I
know that ever asks me how to disable JavaScript asks me because they want to
stop those damn pop-up windows. I think restricting the open() method to one
that requires user input to trigger it (mouseover, mousedown, mouseup, etc)
would fix this once and for all.
Reporter | ||
Comment 6•25 years ago
|
||
> restricting the open() method to one that requires user input to trigger it
that might be good as a site-design rule, but how do you prevent a malicious
site from opening a copy of itself every time you move your mouse over it?
Comment 7•25 years ago
|
||
True. Mouseovers can be passive in many ways. I guess it should be restricted to
events that require explicit user action to visible elements of a page. This
should also have the ability of being disabled altogether (open() calls that
is).
Comment 8•25 years ago
|
||
Norris, you said you had something potentially useful here...
Assignee: rogerl → norris
Component: Javascript Engine → Security: General
QA Contact: rginda → junruh
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M15
Much of the same stuff could be said for the alert() method as well, and maybe
some others... I don't think this should be restricted to just open(). Prefs to
disable certain intrusive Javascript methods (and events?) would be a great idea.
Reporter | ||
Comment 10•25 years ago
|
||
From bug 33448: onclose events should not be allowed to open additional windows
without the user answering 'yes' to a prompt.
Comment 11•25 years ago
|
||
Clearly a cool feature... but we need to branch for the M15 checkpoint, and this
is not a stability stopper. I'm pushing this to M16 (since Norris is out this
week).
Target Milestone: M15 → M16
Comment 12•25 years ago
|
||
please add a [don´t ask next time] checkbox when you add this feature
Comment 13•25 years ago
|
||
Important: to prevent repeating pop-up windows it should be sufficient to let
the onclose event load a page, but this page should be checked if it opens other
windows and if yes, the user should be prompted
prompt the user to act on every onclose event is completly unnecessary and won´t
make mozilla more user friendly
many sites use an onclose event to open a single page, which "says" goodbye to
the user but in fact ends the users session opening a .cgi or .php3 (sometimes
these pages close themselves before the window is rendered), because the
webmaster wants to know when and where a user leaves his site
summary: is should be sufficient to check if the page opened by an onclose event
contains further window.open events and if yes, the user should be enabled to
prevent these from opening
Updated•25 years ago
|
Target Milestone: M16 → M18
Comment 14•25 years ago
|
||
had a great idea this weekend, mozilla should get a "javascript manager" like
the "form manager" and "passwords manager" where user can configure different
"settings" not to be executed,
the first (standard) one would be: prevent window.open() in window.close()
many other could be: 2. aks me on (all/once) window.open in window.close()
3. prevent all window.open in on page opende by window.close()
4. ask me on (all/once) window.open() on page opened by window.close()
5. ask me on window.external.addfavourite() (or how this function is called on
if there´s an equivalent at mozilla - and with this manager one could dangerless
create such an event, because if one can configure mozillas behaviour on such
events, nobody has trouble with "repeating pop-up windows", "bookmars beeing
added" and so on...
experienced users should be able to define "settings" for themselves
Comment 15•25 years ago
|
||
External solutions: Filter
One possible solution for this is for users to use an external rewriting
proxy like proxomitron. It inserts some javascript at the beginning of the
page that redefines the window.open function, or similar.
Still, it would be good to have some kind of fix in the Browser itself.
Assignee | ||
Comment 16•25 years ago
|
||
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Status: ASSIGNED → NEW
Assignee | ||
Comment 17•24 years ago
|
||
Security reviews and denial-of-service attacks. These will be addressed in the
post-beta2 timeframe (unless someone's interested in tackling them earlier?)
Status: NEW → ASSIGNED
Comment 18•24 years ago
|
||
<rant>
Simpler solution: DISABLE OPEN() ENTIRERY. No quotas per site or any of that
nonsense to keep track of.
If I want a link in a new window, I'LL OPEN ONE MYSELF. This is what 'open link
in new window' is for. I will decide when I want two windows, not the site
designer, because he doesn't want me to leave his page as easily as clicking on
a link.
Since aol.com's front page uses open() to pop up a 500-free hour offer in
my face, I'd be surprised to see a netscape engineer do this, but feel
free to prove me wrong.
It should be implemented under preferences->advanced->javascript, which should
also contain options to disable other javascript annoyances. (tickers in status
bar gets my vote...maybe anything accessing the status bar should be
disableable, i want onmouseover default behaviour, not your more user friendly
version of where a link will take me. I end up copying to clipboard and pasting
into Location:, PITA.) All javascript features should be on by default.
I entirerly planed to do this myself once mozilla-1.0 was done, along with a
few other ideas i didn't bother to RFE mozilla.org for, but if it's implemented
as a preferance, it wouldn't really be out of place in the official distro.
</rant>
Assignee | ||
Comment 19•24 years ago
|
||
You can already disable window.open() using configurable security policies...see
http://www.mozilla.org/projects/security/components/configPolicy.html. There's
just no UI for it yet.
Reporter | ||
Comment 20•24 years ago
|
||
*** Bug 9307 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
You want a UI design for this? There's been one in Tardis (see URL) for, like,
*ages*. Here's the relevant morsel:
|| Category Display - JavaScript :::::::::::::::::::::: ||
|| +-------------------+ ||
|| |=General===========| [*] Enable JavaScript ||
|| |=Display===========| ||
|| | Languages | You can forbid scripts from carrying out ||
|| | Fonts | certain actions using the following ||
|| | Colors | settings. ||
|| | Style sheets | ||
|| | Images & Cookies| Action Allowed Forbidden Ask me ||
|| | > JavaScript < | ||
|| | Java | Open new window ...( ).......(*).......( ). ||
|| |=Navigator=========| Load extra images .( ).......( ).......(*). ||
|| |=Messenger=========| Change status bar .( ).......(*).......( ). ||
|| |=Composer==========| Detect window close(*).......( ).......( ). ||
|| |=Chatzilla=========| ||
|| +-------------------+ ::::::::::::::::::::::::::::::::::::::::::: ||
Disclaimer: Design subject to change without notice, especially since keyboard
navigation of this design would be a pain (I'll probably be changing it to a
bunch of popup menus, or something like that). Selections shown do not represent
suggested defaults. All rights reversed. No avocados unless otherwise specified.
Goop for turning this on and off on specific sites can wait until a more general
zones feature is implemented (see URL for a design for that, too). But to have
the ability to turn window.open() on and off, globally, in the back end but not
the front end, is just immensely frustrating.
Comment 23•24 years ago
|
||
Isnt´t it possible to take it from Tardis? I wasn´t able to install a skin, a
package, nothing chrome related...
Comment 24•24 years ago
|
||
Just to clarify, Tardis isn't a chrome package, just a design proposal.
Comment 25•24 years ago
|
||
Marking Future. This is an enhancement request and Netscape no longer has the
resources to do further enhancements between now and RTM.
Moreover, what's being requested here is a significant expansion of what we
attempt to do with the current security model. Historically, we have accepted
that browser DOS attacks will be possible because (1) there are many kinds of
them, and (2) it would be hard impossible to stop them all, and (3) the
workaround is simple: kill the browser, restart, and don't visit the hostile
site again.
Personally, I think this falls into the category of "cool feature that tiny
percentage of power users would love, but most users wouldn't ever understand or
find" and would recommend either WONTFIX or reassigning to nobody@mozilla.org
and marking helpwanted. But I'll leave it assigned to mstoltz for now.
Target Milestone: M18 → Future
Comment 26•24 years ago
|
||
well these repeating pop-up windows are familar to two large blocks
a) porn sites
b) illegal sites (warez...)
and there´s a very high percentage of repeating pop-up windows there
Updated•24 years ago
|
Keywords: helpwanted
Assignee | ||
Comment 27•24 years ago
|
||
Helpwanted is fine, but please leave this assigned to me. This is something I'd
like to look into after RTM. Of course, if any external contributors want to come
up with a fix in the meantime, great...
Comment 28•24 years ago
|
||
If anyone would like a non-porn related demo, I've got a somewhat cleaner
version up and running at <http://www.wpi.edu/~dpotter/infinite.html>. Not only
is it not porn related, the relative code is much smaller, and it should be much
clearer exactly how I'm creating the windows. Plus my version has an "off" link
which disables more windows from appearing.
Comment 29•24 years ago
|
||
Adding self to CC list...
I'd love to see this feature added as PopUp windows onload in general annoy me
(See rant from Jeremy M. Dolan). I really don't think it *needs* to be a
per-site basis as I'd just disable it globally (if I want to see your ad, I'll
click on a link).
Assignee | ||
Comment 30•24 years ago
|
||
Jake,
You can block popups right now by editing your prefs file, see
http://www.mozilla.org/projects/security/components/configPolicy.html
Comment 31•24 years ago
|
||
have you tried it?
on M18 i couldn't get http://www.wpi.edu/~dpotter/infinite.html to stop popping
up windows with the descriptions given on
http://www.mozilla.org/projects/security/components/configPolicy.html
i tried these:
pref("capability.principal.default.window.open", "noAccess");
pref("capability.policy.strict.sites","http://www.wpi.edu");
pref("capability.principal.window.open", "noAccess");
user_pref("capability.principal.default.window.open", "noAccess");
user_pref("capability.policy.strict.sites","http://www.wpi.edu");
user_pref("capability.principal.window.open", "noAccess");
Assignee | ||
Comment 32•24 years ago
|
||
Sorry, the instructions on that page are slightly wrong. All pref lines should
start with capability.policy, not capability.principal. I will fix this soon.
Updated•24 years ago
|
QA Contact: czhang → junruh
Comment 33•24 years ago
|
||
I would also love to see the capability to deny popup windows on the onLoad and
onUnload event handlers. I can also see the possibility for denying <EM>all</em>
popup windows, or only after prompting the user, as there are some folks who
really hate that behavior in any context.
Note this should apply both to JavaScript window.open calls <EM>and</em> to
situations where a TARGET="_blank" (or "_new") attribute is found in an <A HREF>
tag.
Assignee | ||
Comment 34•24 years ago
|
||
You can disable window.open on a per-site basis. Disabling it only in
onLoad/onUnload handlers would be an even finer level of control and would be a
larger change. I'm not sure we need to get this specific...but I'll take patches
for this, of course!
Your second point is well taken, however, clicking a link is a voluntary user
action, whereas a script opening a window is not. If you don't want popup
windows, why would you click the link?
Comment 35•24 years ago
|
||
You might click the link because you don't know it's going to pop up a window,
because you want to see some information in this window. You might just as well
ask "Why go to a site that's going to show you popup windows if you don't want
to see popup windows?"
I'm one of those who would like to be able to disable popup windows entirely.
If I want a new window, I'll do "open link in new window", thank you.
Mitchell: Can I disable window.open on domain *? The security document doesn't
say anything about wildcarding.
Assignee | ||
Comment 36•24 years ago
|
||
The security documentation needs work, I know. The only wildcard available is
the special group name "default," which applies to all sites, or using a scheme
in place of a hostname (including the colon, as in "http:"), which will apply to
all urls of that scheme.
Assignee | ||
Comment 37•24 years ago
|
||
*** Bug 59314 has been marked as a duplicate of this bug. ***
Comment 39•24 years ago
|
||
*** Bug 60167 has been marked as a duplicate of this bug. ***
Comment 40•24 years ago
|
||
even if there is a way to disable popup windows, it would be nice to have
something in the GUI, and maybe something similar to the "Block Image From
Loading" feature, maybe add an option to the menu in windows that have been
created by a page to "Block this window from opening" that would block that
domain from opening any popup windows.
Comment 41•24 years ago
|
||
wow, 52 votes.
> I'm one of those who would like to be able to disable popup windows entirely.
> If I want a new window, I'll do "open link in new window", thank you.
Oh, yes! This is *so* annoying.
However, I don't know, how to prevent that, technically, without blocking the
everything (i.e. making the link completely unusable). Any ideas? Maybe bug 64560?
> Disabling it only in onLoad/onUnload handlers would be an even finer level of
> control and would be a larger change. I'm not sure we need to get this
> specific
It would be very useful. Any useful links are implemented via window.open (see
above) :-(((, but I can't think of an example, where I would like a new window
to open on load. It's almost always an annoying ad (<http://www.netscape.com>,
anyone?). (We wouldn't do the industry in general any harm, since these windows
don't pop up, if you have JS disabled, anyway and the site can advertize in the
main page just fine.)
Making the suggestion a bit more general, it would be cool to have classes of
"triggers" (onload, onclose, onclick, oncommand etc.) as well as classes of
actions and allowing the user to forbid or allow only combinations of them.
Comment 42•24 years ago
|
||
I think totally disabling popup windows would be a bad idea. Many sites
advertise with this, and it is not too hard to click close on those windows.
Taking away the ability to load popup windows would be taking away companies'
ability to advertise - for instance Netscape. I think davidr's idea of a
certain number of popups per site being allowed is best if left simple. Adding
more prefs settings, etc, would just make this bug more complicated. We should
just protect the user from malicious sites (IE: www.crashme.com) and porn sites.
As for the target="_blank", I think that should be allowed since a site
designer might decide to use that when someone clicks on external links. This
allows the user to click on a link and browse the link but stay on the page.
Comment 43•24 years ago
|
||
I disagree.
Advertisements are the main reason I want window.open disabled for OnLoad and
OnUnload. When I'm online I have enough windows open without some overzelous
marketing director deciding for me that I need another one.
As for target=_blank, 99% of the time that's a similar issue in that some web
designer decided that I really didn't want to leave their site and I might have
accidently clicked a link (that they provided, at that) to do so. As stated by
akkana@netscape.com "If I want a new window, I'll do "open link in new window",
thank you."... Really, it's not that difficult to right-click on a link instead
of left-click if you like a page so much that you don't want to leave.
> We should just protect the user from malicious sites (IE: www.crashme.com)
> and porn sites
And how do you keep track of what's malicious and what's not? A big DB of all
"bad sites"? I think that's a bit beyond the scope of building a web browser.
Assignee | ||
Comment 44•24 years ago
|
||
I just composed a long reply, which then got erased when I visited another page
<grumble>
Let me sum up. Configurable security policies, documented at
http://www.mozilla.org/projects/security/components/configPolicy.html
(the typos in the page have now been fixed)
allow you to disable woindow.open() globally or per-site. There's no UI for this
yet, right now it requires editing your prefs file, but UI is coming and is
documented in another bug. To me, the current security model is better than an
arbitrary special-case solution for window.open(), since it can be applied to
any DOM property or function. Yes, it might be nice to be able to block
window.open() only in event handlers, but is the gain really worth the effort of
adding a whole new dimension to the security manager?
The one issue in this bug that I can see which isn't covered by the existing
security manager is the target="_blank" issue. If someone thinks this is
important enough, we could add code to selectively ignore the target field and
just load in the existing window, though I think this would break a lot of sites.
Except for the need for a UI, I think this issue is already solved. I'll post
some more specific examples of how to disable popup windows. Comments?
Comment 45•24 years ago
|
||
>Yes, it might be nice to be able to block
>window.open() only in event handlers, but is the gain really worth the effort
> of adding a whole new dimension to the security manager?
agreeing, I hope I am able to block crasher scripts like this too then:
<img src="banner.gif" onload="for(a=0; a<1;
a--){window.open('http://www.mozilla.org')}">
if so, it could be one of the predifined settings, to disallow infinite loops, I
hope it is configurable up to this level
about the "_target" issue, I do not worry if it is possible to avoid
"_target"-opening-windows, but it should *not* be enabled by default, it would
break *many* sites
Comment 46•24 years ago
|
||
The configurable security policies sound like a nice general way of
accomplishing this, if I'm reading the page right; I agree that it's better than
a special-case solution. But it doesn't seem to work for me: I set
user_pref("capability.policy.default.window.open", "noAccess");
but sites can still open a popup window. Maybe that's because the page I tried
uses target= to accomplish this? I definitely think ignoring target= (not just
blank, but any target) is an important part of this bug since it's probably the
most common way sites have of opening new windows. To the user, there's no
difference between a JS-created new window and a target= new window.
Comment 47•24 years ago
|
||
> I definitely think ignoring target= (not just
> blank, but any target) is an important part of this bug
If this part were implimented, it should be in the form of ignoring any target
for which there isn't a window by that name. Arbitrarily ignoring a target
would break almost every framed site in existance.
Changing URL from http://critique.net.nz/project/mozilla/prefs/tardis/ to the
configPolicy
Reporter | ||
Comment 48•24 years ago
|
||
I still think there should be a limit on the number of windows a given window
can window.open() in addition to a way to completely disable window.open(). I
doubt Netscape marketing would allow NS to ship with window.open set to
noAccess by default, but without that setting the browser currently ships
vulnerable to a very annoying (and widely exploited) denial-of-service attack.
Bug 64472 should be marked as a dup of the bug for UI for completely disabling
window.open. We also need another bug for discussing target= and what happens
when it's "disabled" (bug 56296?).
Comment 49•24 years ago
|
||
Bug 56296 is specific to disabling the opening of new windows with the target
attribute.
Several people have said this would break some sites... any examples of how that
would happen? Some sort of complex JS hackery? All the uses of target=_blank
I've seen were cases of badly-behaved web designers trying to stop people from
leaving their sites easily.
Comment 50•24 years ago
|
||
Filed bug 64737 about my suggestion.
Comment 51•24 years ago
|
||
Mitchell Stoltz has said:
>Yes, it might be nice to be able to block window.open() only
>in event handlers, but is the gain really worth the effort of
>adding a whole new dimension to the security manager?
I don't know the code base, so I don't know how much it would break to be able
to do that. But as a user, I know that I would truly *love* to be able to simply
stop any site in the world from spawning popups based on BODY onLoad and BODY
onUnload, and then forget about the problem.
Assignee | ||
Comment 52•24 years ago
|
||
*** Bug 57908 has been marked as a duplicate of this bug. ***
Comment 53•24 years ago
|
||
See bug 56296 for a patch for the target=_blank or target=_new problem.
Comment 54•24 years ago
|
||
*** Bug 18441 has been marked as a duplicate of this bug. ***
Comment 55•24 years ago
|
||
*** Bug 64472 has been marked as a duplicate of this bug. ***
Comment 56•24 years ago
|
||
The configurable security policy prefs don't work for JS popups, either. For
example, they don't block the popup on netscape.com.
Comment 57•24 years ago
|
||
Ben Goodger posted the real syntax just now: turns out that it's
pref("capability.policy.annoyances.sites", http://home.netscape.com");
pref("capability.policy.annoyances.window.open", "noAccess");
to disable specific sites, and I played around with it and came up with
pref("capability.policy.annoyances.default.window.open", "noAccess");
to disable it in general.
Hallelujah! Whoever owns the security policy document might want to take note
that it's out of date.
Comment 58•24 years ago
|
||
No, strike that; I thought that generic form was working but it must have been a
momentary glitch on the part of netscape.com; now it's giving me popups again.
The specific form still works, so one can block popups on particular sites if
one knows in advance which sites to block.
Can anyone please tell us what the correct generic form of the pref is?
Comment 59•24 years ago
|
||
Looking at the code, it's not obvious how any of the defaults get set.
nsScriptSecurityManager::EnumeratePolicyCallback has an if (!isDefault), then in
the else clause, it does another else (!isDefault) so if isDefault is true it
ends up doing nothing. Curiously, this routine is called for lots of other
capability.policy.default prefs which don't match the built-in dom props, and
doesn't set a bit for any of them.
But "capability.policy.annoyances.default.window.open" doesn't even get that
far; in findDomProp, it compares the string against a list of 10 different dom
props, fails to find a match and returns NS_DOM_PROP_MAX, which triggers an
assert, "DOM property name invalid or not found". This also happens for
"capability.policy.default.window.open" and
"capability.policy.default.annoyances.window.open".
Are default capabilities dealt with somewhere else? I looked for some of the
other prefs that are set in all.js but don't match the dom prop list, and
couldn't find other handlers.
Assignee | ||
Comment 60•24 years ago
|
||
I think the pref line is actually
user_pref("capability.policy.default.windowinternal.open","noAccess");
for blocking window.open universally. Sorry, I know the documentation on the
page I mentioned above is out of date. Let me double-check that the feature
works and post some updated docs; then I should get Ben to help me write a UI.
Assignee | ||
Comment 61•24 years ago
|
||
OK, I've just tested the following and it works just fine: to block popups from
a specific site or group of sites, add these lines to bin/defaults/pref/all.js
(turns out you have to add these to all.js, not prefs.js, I think):
pref("capability.policy.popupsites.sites", "www.annoyingsite1.com
www.popupsite2.com [and so on, space-separated list of URLs]");
pref("capability.policy.popupsites.windowinternal.open","noAccess");
The first line defines a group (the equivalent of a "security zone" in IE)
consisting of a list of sites, and the second line forbids these sites from
opening new windows. Try it, it works!
Assignee | ||
Comment 62•24 years ago
|
||
Actually, the URLs in the above example have to start with http:// (or ftp or
whatever). Don't leave off the protocol.
Comment 63•24 years ago
|
||
The default version of the pref is working fine for me. I've updated the
customizing document with both the default and specific syntaxes. Thanks very
much, Mitchell!
Comment 64•24 years ago
|
||
Ok, so when is this going to be put on the tree? (For people like me that are
too lazy/busy to apply manually)
Comment 65•24 years ago
|
||
mstoltz, if you have to put a (user) pref in all.js, not prefs.js, there's
something horribly screwed up, since the prefs functions usually do all this
stuff automatic, not? If you are right, can you file a bug?
Comment 66•24 years ago
|
||
I'm blocking *all* popup windows by adding a line to prefs.js in my profile
directory. At least part of prefs.js works....
Comment 67•24 years ago
|
||
I have these set in my user.js, and they seem to be working there ...
Comment 68•24 years ago
|
||
*** Bug 66797 has been marked as a duplicate of this bug. ***
Comment 69•24 years ago
|
||
*** Bug 67395 has been marked as a duplicate of this bug. ***
Comment 70•24 years ago
|
||
This should definately be considered. CNet is running an article about how this
is become a new defacto standard for advertisments. Much like Mozilla's "accept
images only from originating server" option, a "confirm" box (or, at the least,
an enable/disable option) gives users more control over what ads they will
otherwise be "forced" to see.
Referenced article:
<a href="http://news.cnet.com/news/0-1005-201-4687442-0.html">CNet Article</a>
Comment 71•24 years ago
|
||
*** Bug 68060 has been marked as a duplicate of this bug. ***
Comment 72•24 years ago
|
||
*** Bug 69554 has been marked as a duplicate of this bug. ***
Comment 73•24 years ago
|
||
How many duplicates does a bug need to be mostfreq? This one has 11. And 56
votes (counting mne).
Comment 75•24 years ago
|
||
What exactly are people looking for besides the security prefs which are working
now? I guess maybe Mitchell knows, having not closed the bug yet, but I'm
curious. The popup blocker is working great for me (though I wish I had a way
to disable it temporarily since I occasionally go to sites that don't work
without JS popups).
Comment 76•24 years ago
|
||
I have another idea - instead of trying to catch window.open on an onclose()
event, we could:
a) not send the onclose() event if the window was opened via window.open(), or
b) not send the onclose() event if the user closed a window with some
special modifer (e.g. shift-close would prevent the event)
Comment 77•24 years ago
|
||
Akkana asked:
>What exactly are people looking for besides the security prefs which
>are working now?
I'd still ike to see the ability to block popups on particular events,
*regardless of domain*. I'd like to be able to put in a blanket prohibition on
popups or other means of spawning new windows on onLoad, onMouseOver, and
onUnload (or onClose) events, but leave them for things like onClick.
At the moment, I don't see any way of doing that.
Comment 78•24 years ago
|
||
As far as I can see, this is about a site preventing a site from opening popups
ad infinitum, whether by maliciousness or programmer error. This feature should
be there regardless of domain.
Assignee | ||
Comment 79•24 years ago
|
||
1) The popup blocker backend already works. Akkana, if you want, you can block
popups by default and then exempt certain sites from the blocking.
2) UI for this is coming. There's another bug about that.
3) Doing securoty policy for specific event handlers would be a major addition
to our current security model, and I don't plan to do that anytime soon.
However, this is an open project and I am happy to take patches for that feature
if someone wants to write them.
4) There's already a bug open somewhere for the "ad infinitum" case, also called
"trivial denial of service." That's a hard problem to solve, and personally I
don't consider it a high priority. How do you tell malicious window-opening from
legitimate, other than by allowing users to block particular sites? What's the
threshold of "ad infinitum?"
Most of the issues raised here are all covered by other bugs or else already
fixed. I'll leave this open as an RFE for blocking-by-event-handler, in case
anyone wants to implement that. Changing description and marking helpwanted.
Keywords: mostfreq
Summary: Prevent repeating pop-up windows → Block window.open() based on event handler
Reporter | ||
Comment 80•24 years ago
|
||
Blocking-by-event-handler is bug 64737, but I'm pretty sure this was the bug
for the "ad infinitum" case (at least that's what it was when it was first
reported). I don't think this should be changed to be about blocking by events
because it has gathered many votes as a bug somewhere between "ad infinitum"
and "let me disable window.open() completely".
I'm going to change the summary of this bug back but leave the mostfreq keyword
off since many of the bugs marked as dups were asking for UI to completely
disable window.open(). (Which bug tracks that issue now, by the way?)
Summary: Block window.open() based on event handler → Prevent repeating pop-up windows
Comment 81•24 years ago
|
||
I think what's needed here is a view of simplicity.
what's the goal of this bug? "To prevent repeating pop-up windows"? I don't
think so.
In fact, I think the goal of this bug really is to ask for more control over
*what* gets to open those windows.
As you've said, the DoS case of this bug is solved, but what of the sites that,
as you exit them, open 4 new windows that, when you close, open 4 more? that is
the case that needs addressing here.
In my mind there are two ways to fix this issue, and they have both been
suggested already:
1 - Choose the event(s) in which pop-up windows should be allowed.
Most of the "annoying" cases occur when closing windows. Most of the "justified"
cases occur as a result of a mouseclick. Offering the option to disable one but
not the other would help immensely. Further, as opening multiple popups is
becoming an advertising standard at many websites now, a way to disable that
behaviour would also be of use.
2 - prevent repeating windows by preventing "popups" from opening other "popups".
This would solve the most severly annoying case, and is easily achieved with one
menu option to enable or disable this feature. This wouldn't stop the "first"
popup, but it would stop the "endless chain" of popups. For this option, and
additional feature, to disable popups entirely, could also be offered.
Just my summary on the issue thus far. :)
Comment 82•24 years ago
|
||
What about a pref (even better menu item) analogous to these for cookies and
images "Ask when opening a pop-up window". It would be ideal if I could answer
"Never for this site".
Assignee | ||
Comment 83•24 years ago
|
||
listen to yourself! Open a dialog to ask if you want a dialog to be opened? The
simplest way to deal with this problem is exactly what we're doing - if you find
a site that does any sort of annoying popups, you will be able with a minimum
effort to block popups coming from that site. That's the feature as I see it and
that's what I'm implementing. Anyone wanting additional functionality, please
feel free to write it yourself.
Comment 84•24 years ago
|
||
I do not see any problem with opening a dialog asking if I want a pop-up window
to be opened by this particular site/domain. If you really want a zillion pop-up
windows to open, you simply answer "yes" and add an x to "Remember this
decision" (this way you need not answer a zillion Mozilla dialogs aw well).
Anyway, I do not want this dialog to be the default, of course. Rather a setting
for people who know what they are doing.
Or maybe are you afraid of JavaScript pop-up windows disguised as the Mozilla
dialog window about pop-ups? Well, the Mozilla dialog would always be the first
to appear if you have the seting "on". If you have it "off", you would not be
mislead by it, anyway.
Comment 85•24 years ago
|
||
I have to disagree.
Does mozilla offer a per-site option to disable Javascript? No.
Does Mozilla offer a per-site option to disable Java? No.
Can you turn these options on and off now? Yes.
you can disable popups RIGHT NOW by disabling Javascript. Of course this is
obviouslly a suboptimal solution, as many sites won't work with Javascript disabled.
On that same line of thought though, why not disable window.open? Or disable
window.open as a result of a window.close? As I said in my post above, that
solves the problems with there without you having to add each offending site to
an ever-expanding list. In the only cases where you DO keep a list (cookies,
forms), you get a requester asking you for such. You advocate against this (I
believe rightly). Choosing the javascript events on which a popup should be
allowed is simply providing a finer-grained "disable javascript" option, and (as
I've said) satisfies most of the cases of this happening.
Comment 86•24 years ago
|
||
OK, Ken. I see the point. But why not do both:
- a setting to disable window.open and/or window.open as a result of a window.close
- a setting like "Disable JavaScript per-site" (a better wording is probably
needed), similar to the cookies and images ones.
This way everybody would be satisfied (including the people who feel no need to
disable JavaScript).
Comment 87•24 years ago
|
||
Oh, I definately have no problem with the Latter! I was actually only countering
Mitchell's comment that we were 'opening a dialog to ask if we wanted to open
another dialog'.
If the security policy-aspects can be easily integrated as well, I say by all
means do so! I was simply trying to draw a parallel with the 'current
functionality' in Mozilla. :)
Assignee | ||
Comment 88•24 years ago
|
||
All right already! We're beating a dead horse. I've said this several times in
this and other bugs, so this will be the last time: you *can* disable
window.open, or all JS execution, or any DOM properties, on a per-site basis, by
editing your prefs. UI for this is coming soon and documented in another bug.
I think the purpose of this bug has become utterly confused, so I'm going to
close it. If you're interested in features besides per-site blocking of specific
DOM properties (the ones I've seen in this bug are blocking based on event and
some way of preventing trivial DoS with multiple window opening), please open
another bug and be very specific about the feature you'd like to see.
Personally, I think per-site blocking with a simple UI is sufficient, but if you
guys want to make the security model more complicated, you're free to implement
it yourself.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 89•24 years ago
|
||
EVERYONE: Since this bug was closed without really resolving what most of us
want, I have created a new bug 75371 that specifically requests a UI to handle
pop-up windows (and other javascripts).
Doing this on a "per site basis" as Mitchell Stoltz offered as the final
solution before closing this bug is not good enough because you usually don't
know the offending site before it's too late (you're already there). Also, we
don't want to have to *edit* our prefs, we are normal users and need a front end ;)
My bug only deals with the UI, but maybe someone will create a bug for the back
end and mark it "bug blocks" bug 75371.
I suggest you all go to the new bug 75371 and move your votes you casted here to
the new bug. ;) That way it might get the attention it needs.
Maybe this time it'll work ;)
Comment 90•24 years ago
|
||
Actually that bug was marked a duplicate. Move your votes to bug 38966 - That's
where the work is being done.
Comment 91•24 years ago
|
||
Marking VERIFIED FIXED, since Mitch's comments indicate closure due to
confusion & Ken indicated another bug exists...
Status: RESOLVED → VERIFIED
Comment 92•23 years ago
|
||
*** Bug 80288 has been marked as a duplicate of this bug. ***
Comment 93•23 years ago
|
||
*** Bug 81619 has been marked as a duplicate of this bug. ***
Comment 94•23 years ago
|
||
*** Bug 95155 has been marked as a duplicate of this bug. ***
Comment 95•23 years ago
|
||
See also bugs I made for further controlling the activity of popup windows:
Bug 114993: Max level of popup windows
Bug 114994: A sidebar for denied popup windows
You need to log in
before you can comment on or make changes to this bug.
Description
•