161516 - window.open works in onunload in tabbed window but not in normal window

Status: RESOLVED FIXED

(SeaMonkey :: Tabbed Browser, defect)

Description

[stan]

When you have 2 or more tabbed browser windows and when you have an onUnload
event that fires a window.open the new window pops up.  But when you only have 1
tabbed window the window.open is not opening a new window. There is clearly an
inconsistency.

In our application (my company's) we need to open a new window (the architecture
flow) when a user exits a window (some cleanup and unlocking) but this is not
possible even when the Edit > Preferences > Advanced > Scripts & Plugins > Open
Unrequested Windows is set.  Is there anyway to open a new window when the
onUnload event occurs.  This is really needed for our product in order for us to
support Netscape and Mozilla (and we really want that).

What I suggest is to make this feature consistent and also have an additional
preference to enable 'onUnload Popups' if the user choses to (just like the
onLoad Popups).

Thanks guys for your consideration and help,
Stanley Kubasek

Comment 1

[Jesse Ruderman]

window.open was intentionally disabled for non-tabbed windows in bug 33448.

Comment 2

[stan]

So there is no way for me to successfully call window.open on the onUnload 
event?  Can this be enabled manually in my browser? Any settings, preferences 
that will make it possible in my case?

Comment 3

[Joseph R. Dietrich]

So why disable window.open() on window.onunload events for closing a window, but
not for closing a tab! After all, the stated reason seems to be because of abuse
by malicious webmasters using "hydra ads" -- but if you browse with many tabs
(like I do), then you have a similar problem.

Comment 4

[stan]

I totally agree with you. They should at least make a preference which you can 
set on your own (like they do with onLoad event). That way a user has an option 
to allow it or not.

Comment 5

[Kai Lahmann (is there, where MNG is)]

I would say disable in for tabbed browsing too.

stan: be warned, for the people I know, 9 out of 10 come never back, if a page
has a onunload popup, this is seen as being very inpolite.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Confirming bug, in any case.  ccing mitch, since he should be in on this.

We _should_ consider adding an (off by default) pref that allows new windows in
onunload, imo.

Comment 7

[stan]

I think it would do no harm to those that don't need it (since it will be off by
default - like suggested) and for those that need it (like myself, since this is
a requirement for our internal application) would make use of it.

Please make the change since I think it would enhance the functionality of the
browser (at least for some users; and IE is using it by default, anyway). 
Appreciate it, thanks!

Comment 8

[Jesse Ruderman]

*** Bug 161680 has been marked as a duplicate of this bug. ***

Comment 9

[Dan M]

  I argue that this is a duplicate of bug 130719. I'm not closing it as such
because it's arguably not; I'll leave it to the owner.
  Really the issue is that popups can't be opened from a window being destroyed
regardless of the pref's value (see that bug and bug 115969). Closing a tab
doesn't destroy the window, so popups aren't disallowed in this case.

Comment 10

[Jesse Ruderman]

I think allowing onunload pop-ups should be a separate, hidden pref that
defaults to off.

Comment 11

[jag (Peter Annema)]

stan, do you have a URL or a testpage you could attach so we can see whether
we've addressed your issue with the fix for bug 130719?

Comment 12

[stan]

I tested this feature on Mozilla 1.2b and this feature works correctly. New
pop-up windows can now be opened onUnload as well as alert() box can be shown
(which is the related bug).  

Also, please do not remove this functionality - preference - from future releases.

Thanks guys!

Comment 13

[jag (Peter Annema)]

danm, dveditz, could this have been "fixed" as a side effect to changes recently
made in those areas of the code?

Comment 14

[Dan M]

Yes. This is really a duplicate of bug 130719. It's fixed and we have no
intention of unfixing it.