Closed Bug 29346 Opened 22 years ago Closed 21 years ago

Prevent repeating pop-up windows


(Core :: Security, enhancement, P3)






(Reporter: jruderman, Assigned: security-bugs)


(Blocks 1 open bug, )


(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.
*** This bug has been confirmed by popular vote. ***
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?
Similar to bug 9307
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.
> 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?
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 
Norris, you said you had something potentially useful here...
Assignee: rogerl → norris
Component: Javascript Engine → Security: General
QA Contact: rginda → junruh
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.
From bug 33448: onclose events should not be allowed to open additional windows 
without the user answering 'yes' to a prompt.
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 
Target Milestone: M15 → M16
please add a [don´t ask next time] checkbox when you add this feature

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 events and if yes, the user should be enabled to
prevent these from opening
Target Milestone: M16 → M18
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 in window.close()
many other could be: 2. aks me on (all/once) in window.close()
3. prevent all in on page opende by window.close()
4. ask me on (all/once) 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
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 function, or similar.
Still, it would be good to have some kind of fix in the Browser itself.
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Security reviews and denial-of-service attacks. These will be addressed in the 
post-beta2 timeframe (unless someone's interested in tackling them earlier?)
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'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 for, but if it's implemented 
as a preferance, it wouldn't really be out of place in the official distro.
You can already disable using configurable security policies...see There's 
just no UI for it yet.
*** Bug 9307 has been marked as a duplicate of this bug. ***
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 on and off, globally, in the back end but not 
the front end, is just immensely frustrating.
Assigning QA to czhang
QA Contact: junruh → czhang
Isnt´t it possible to take it from Tardis? I wasn´t able to install a skin, a
package, nothing chrome related...
Just to clarify, Tardis isn't a chrome package, just a design proposal.
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 
and marking helpwanted. But I'll leave it assigned to mstoltz for now.
Target Milestone: M18 → Future
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
Keywords: helpwanted
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...
If anyone would like a non-porn related demo, I've got a somewhat cleaner
version up and running at <>.  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.
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).
  You can block popups right now by editing your prefs file, see
have you tried it?
on M18 i couldn't get to stop popping
up windows with the descriptions given on

i tried these:

pref("", "noAccess");
pref("", "noAccess");
user_pref("", "noAccess");
user_pref("", "noAccess");
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.
QA Contact: czhang → junruh
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 calls <EM>and</em> to 
situations where a TARGET="_blank" (or "_new") attribute is found in an <A HREF> 
You can disable 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?
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 on domain *?  The security document doesn't
say anything about wildcarding.
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.
*** Bug 59314 has been marked as a duplicate of this bug. ***
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
*** Bug 60167 has been marked as a duplicate of this bug. ***
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.
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 (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 (<>,
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.
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: 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.
I disagree.
Advertisements are the main reason I want 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 "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:
> 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.
I just composed a long reply, which then got erased when I visited another page

Let me sum up. Configurable security policies, documented at
(the typos in the page have now been fixed)
allow you to disable 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, since it can be applied to
any DOM property or function. Yes, it might be nice to be able to block 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?
>Yes, it might be nice to be able to block
> 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;

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
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("", "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.
> 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 to the
I still think there should be a limit on the number of windows a given window 
can in addition to a way to completely disable  I 
doubt Netscape marketing would allow NS to ship with 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  We also need another bug for discussing target= and what happens 
when it's "disabled" (bug 56296?).
Bug 56296 is specific to disabling the opening of new windows with the target

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.
Filed bug 64737 about my suggestion.
Mitchell Stoltz has said:

>Yes, it might be nice to be able to block 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.
*** Bug 57908 has been marked as a duplicate of this bug. ***
See bug 56296 for a patch for the target=_blank or target=_new problem.
*** Bug 18441 has been marked as a duplicate of this bug. ***
*** Bug 64472 has been marked as a duplicate of this bug. ***
The configurable security policy prefs don't work for JS popups, either.  For
example, they don't block the popup on
Ben Goodger posted the real syntax just now: turns out that it's
pref("", "noAccess");
to disable specific sites, and I played around with it and came up with
pref("", "noAccess");
to disable it in general.

Hallelujah!  Whoever owns the security policy document might want to take note
that it's out of date.
No, strike that; I thought that generic form was working but it must have been a
momentary glitch on the part of; 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?
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 "" 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
"" and

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.
I think the pref line is actually

for blocking 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.
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", " [and so on, space-separated list of URLs]");

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!
Actually, the URLs in the above example have to start with http:// (or ftp or
whatever). Don't leave off the protocol.
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!
Ok, so when is this going to be put on the tree? (For people like me that are 
too lazy/busy to apply manually)
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?
I'm blocking *all* popup windows by adding a line to prefs.js in my profile
directory.  At least part of prefs.js works....
I have these set in my user.js, and they seem to be working there ...
*** Bug 66797 has been marked as a duplicate of this bug. ***
*** Bug 67395 has been marked as a duplicate of this bug. ***
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="">CNet Article</a>
*** Bug 68060 has been marked as a duplicate of this bug. ***
*** Bug 69554 has been marked as a duplicate of this bug. ***
How many duplicates does a bug need to be mostfreq? This one has 11. And 56
votes (counting mne).
Current rule of thumb is 10.
Keywords: mostfreq
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).
I have another idea - instead of trying to catch on an onclose()
event, we could:

a) not send the onclose() event if the window was opened via, 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)
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.
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.
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 based on event handler
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 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  (Which bug tracks that issue now, by the way?)
Summary: Block based on event handler → Prevent repeating pop-up windows
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. :)
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".
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.
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.
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 Or disable 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.
OK, Ken. I see the point. But why not do both:
- a setting to disable and/or 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).
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. :)
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, 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.  
Closed: 21 years ago
Resolution: --- → FIXED
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 ;)
Actually that bug was marked a duplicate. Move your votes to bug 38966 - That's
where the work is being done.
Marking VERIFIED FIXED, since Mitch's comments indicate closure due to 
confusion & Ken indicated another bug exists...
*** Bug 80288 has been marked as a duplicate of this bug. ***
*** Bug 81619 has been marked as a duplicate of this bug. ***
*** Bug 95155 has been marked as a duplicate of this bug. ***
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
Blocks: popups
You need to log in before you can comment on or make changes to this bug.