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. ***

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 is).

Norris, you said you had something potentially useful here...

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 week).

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 window.open events and if yes, the user should be enabled to prevent these from opening

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

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.

Bulk reassigning most of norris's bugs to 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?)

<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>

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.

*** 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 window.open() on and off, globally, in the back end but not the front end, is just immensely frustrating.

Assigning QA to 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 nobody@mozilla.org and marking helpwanted. But I'll leave it assigned to mstoltz for now.

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

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 <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.

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).

Jake, You can block popups right now by editing your prefs file, see http://www.mozilla.org/projects/security/components/configPolicy.html

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");

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.

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.

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?

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.

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.

*** 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 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.

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.

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.

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?

>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

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.

> 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

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?).

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.

Filed bug 64737 about my suggestion.

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.

*** 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 netscape.com.

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.

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?

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.

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.

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!

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="http://news.cnet.com/news/0-1005-201-4687442-0.html">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.

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 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)

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.

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?)

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 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.

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).

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 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.

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