Closed Bug 33448 Opened 25 years ago Closed 23 years ago

disable 'new window' when close box clicked (no window.open in onUnload)

Categories

(Core :: DOM: Core & HTML, enhancement, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: warrensomebody, Assigned: danm.moz)

References

(Blocks 1 open bug,
URL
)

Details

When a close box is clicked on a window, the first thing we should do is disable the ability for javascript to open new windows. If the user is closing, they usually want to get out of the damn thing, not see another stupid window. I think the onUnload handler is the one that needs to be "fixed." Somebody sent me the idiotic url above. If you go to the page and then click the go back button a pop-up window appears (that says "Wait!"). If you close that window, another one appears. Annoying.
Special case of bug 29346, "prevent repeating pop-up windows".
Moving beond beta2
Status: NEW → ASSIGNED
Target Milestone: --- → M18
This bug has been marked "future" because the original netscape engineer workingon this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M18 → Future
Assigning to scc, because when you're surfing porn, this is the number one bug you want to have fixed.
Assignee: jst → scc
Status: ASSIGNED → NEW
I wonder who the right person to fix this is? Perhaps danm@netscape.com ? He has window knowledge. Or should this belong to a JS person? Danm is used to finding the middleground between cooperating components. Probably, he is the one who could make this happen. This sounds like a good thing ... Dan, note that this bug is marked 'Future'.
Assignee: scc → danm
This is covered by 29346, specifically, it's covered in Tardis's prefs.
*** Bug 40005 has been marked as a duplicate of this bug. ***
See also bug 64737.
I think, the onUnload handler was a bad idea in the first place and should be disabled. I cannot see a valid usage for it. If you decide to disable for window.open in onUnload only, this bug would be a special case of (i.e. dependant on) bug 64737.
Isnt this a dupe of bug 56296?
This bug is for adding the ability to prevent window.open() in onUnload; 56296 is for making a pref for target=_blank links to target the current window instead of new window. I don't see why this would be a dup.
Keywords: dom0
Keywords: dom0
There were comments in this bug about disabling the onUnload event. Please, no. This is a very important event for anyone writing DHTML applications that need to do cleanup when the window closes. I've used it to CLOSE "child windows" for the DHTML app (ironically, the reverse of what this bug is about) and to prevent dataloss by capturing entries made into a form and sending it to a parent window. window.open in onUnload is evil in basically every case I can think of. It wouldn't be a loss if window.open was eliminated in the onUnload event. Just keep onUnload around. :) I think this bug is more accurately titled "disable 'new window' when leaving a page or when close box clicked". The annoying behavior described by the reporter includes both. Preventing window.open in the onUnload event fixes both.
Summary: disable 'new window' when close box clicked → disable 'new window' when close box clicked (no window.open in onUnload)
*** Bug 80647 has been marked as a duplicate of this bug. ***
Depends on: 64737
Keywords: helpwanted
OS: other → All
see also bug 92955, which I should probably mark as a dupe. danm, I'll take this.
bug 92955 does just this and has been fixed. dup?
[slightly OT] If bug 92955 fixes this, what then is the pref to prevent a new window when onUnload? [/slightly OT]
*** This bug has been marked as a duplicate of 92955 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I'm not sure that this is a dup of bug 92955. That bug affects window.open in both onload and onunload as near as I can tell. While it's arguable that they're both annoying, window.open in onload has worthwhile uses, while the onunload case has almost none. Is there a way to turn off one but not the other in bug 92955? Or is this really a more specific case of bug 64737?
Reopening. This bug is about disabling window.open in onunload *by default* (with or without a pref), and bug 92955 was about adding a pref to disable it.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Jesse, no, this bug is about disabling window.open in onload and onunload seperately. The reporter wants to be able to allow onload windows but not onunload windows. It actually shouldn't be that hard. It just involves adjusting the listeners from the other bug. On the issue of whether this should be default, the answer is NO. that would break our compliance with ECMAScript. We must offer the ability to do this, but should have a pref to disable it for the user.
Blocking window.open in onunload by default would not break our compliance with ECMAScript, because the ECMAScript specification says nothing about either window.open or onunload. Onunload is an event defined by the HTML4 spec, and window.open is not standardized anywhere. Even if window.open were standardized, that wouldn't force us to make it successful whenever it is called; the W3C DOM specs leave security up to the user agent. Disabling window.open in onunload would break our compatibility with "hydra" pop-up ads, and that's pretty much it.
[Aufbau-P1]: Pop-up ads have interfered with porn surfing for too long.
Whiteboard: [Aufbau-P1]
Whiteboard: [Aufbau-P1]
Implementing this would improve the user experience. Blocking this behaviour would allow Mozilla to help the confidence of people who are learning. When they encounter a malevolant link they need to retain control of what the browser is doing and not be locked into some daft or malicious loop. Can anyone think of an instance where opening windows in this way is *not* malevolant? Visiting the following with IE caps any unpleasantry into which Mozilla can be hijacked as the site sets a page of its choice as the windows active desktop, so Mozilla's already ahead there ... suppressing the ability of a window to open a new one when it is closed, and making the preference to choose to suppress windows opened by web pages easy to find, would help with the rest ... eg 11/01/2001 Starting from: http://www.bubl.ac.uk/link/c/chemicaldata.htm Followed link to 'Chemglobe': ended up at the following http://periodictable.tsx.org/ Page content is: Please remove your bookmarks pointing to the url http://periodictable.tsx.org The redirection service of www.tsx.org has changed without any notice, and "features" now popup-advertising with pornographic content. Please simply use the absolute URL http://www.vcs.ethz.ch/chemglobe/ptoe/ instead
justsaywow.com have since relented; the annoying "wait" window is gone in any case. Even better, this bug/enhancement has been fixed, since it cloaked itself in a crash in bug 115969. You can now visit periodictable.tsx.org, the most obnoxious site I've ever visited hands-down or not, in relative fearlessness. They do still manage to open one window that can't be closed at all; not until you've closed every other window. There's a neat trick. I'll have to look into how they managed that. The code is on the trunk. It'll show up in the 0.98 build.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Keywords: helpwanted
Resolution: --- → FIXED
Target Milestone: Future → mozilla0.9.8
*** Bug 98923 has been marked as a duplicate of this bug. ***
I have encountered the implementation of this feature while developing a web-based application. Unfortunately, I did not find this bug in my search for answers, so I created the bug 130947, where I was directed here. I strongly disagree with hard-coding the disabling window.open() when the window is being closed. I do believe that it should be a configurable option. I would even agree that the configuration default should be disabled. Mark Annand (in comment 23) asked "Can anyone think of an instance where opening windows in this way is *not* malevolant?". Yes, I can. In any web-based application (note that I am not talking about e-commerce and the like) you can provide a better user experience if more control is available. My web-based application is attempting to mimic a traditional Windows-based application, in that if the user is editing data and attempts to close the window I would like to be able to pop up a new application window, taking them right back into the application and prompt them with a save/abandon changes dialogue. Ditto for closing database connections. I could rely on middleware session timeouts, but it is a much less cohert user experience. Comments?
The above reason if too trivial and irrelevant to Mozilla the browser to justify open the flood gates of popup windows. It should stay a configurable option. If vendors want to create apps, they should be able to set a default in *their* app, and perhaps disable the pref in *their* app.
So you are telling me it IS configurable. How? The only reference I can find to this is in the "Configurable Security Policies" page, where you can do the following: user_pref("capability.policy.policynames", "trustable"); user_pref("capability.policy.trustable.sites", http://my.intranet.com"); user_pref("capability.policy.trustable.Window.open", "sameOrigin"); This doesn't seem to help in my situation. BTW, is it "too trivial and irrelevant" to drive application developers to be forced to use IE instead? I believe the industry is at a balance point where certain choices could drive application development back to MS or turn it completely to industry standards. One of the major problems in a non-MS direction is a standard, WIDELY ACCEPTED browser other than IE. Mozilla is progressing well to be that browser, but...
Yes, it is configurable under: Edit / preferences / Advanced / Scrips & Windows [OT] Also, threats will achieve *NOTHING* here. Nobody is "forced" to use MS. [/OT]
Peter: I don't think Mozilla has an option to allow window.open in onunload events. Bart: I think what you really want is something like Internet Explorer's unbeforeunload event, which would allow you to put up a dialog asking the user if they want to cancel closing the window in order to save their changes. That would make more sense than trying to open a new browser window. See bug 68215.
It was not my intention to threaten anyone. Actually, post 11 from bug 68215 is making the same point as I am. I have to get my application working to the satifaction of the users. If I can't do that with Mozilla, I have no choice but to use IE. That's reality. Please don't misunderstand. I would like to avoid using IE if possible. My Edit/Preferences/Advanced/Scripts & Windows has everything checked and it still doesn't work. The unbeforeunload event, as mentioned in bug 68215, would be perfectly acceptable to me.
See also bug 161516, "window.open works in onunload in tabbed window but not in normal window".
See also bug 130947, "window.open() fails in OnUnLoad".
See also bug 130719, "onUnload doesn't permit alerts()'s when window is closed."
An update on this bug: bug 92955 lets the user set a pref whether to allow a window being closed to open a new window. Recent complaints in this bug 33448 were caused by the fix for bug 115969 which ignored that pref in favour of fixing a crash; windows were not allowed to open new windows regardless. This last thing has been rescinded; windows now pay attention to the 92955 pref. The 115969 crash fix has been replaced by the less draconian version in bug 130719.
Blocks: popups
This regressed with the fix for bug 130719. Scripts can once again open windows during the onunload event in Mozilla's default configuration :(
We had to implement it for "DOM 0 compliance." It's configurable, whether to allow a site to do this. At the moment popup blocking is an all-or-none thing: Edit > Preferences > Advanced > Script & Plugins > Allow Scripts to Open Unrequested Windows. Windows opened in the unload handler are a kind of unrequested window. For a while we had site-by-site control, rather than all-or-nothing. That's gone now but should return in Mozilla 1.3. See bug 166442.
You need to log in before you can comment on or make changes to this bug.