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.