655024 - DOM in FX4 and SM 2.1b3: modal dialogs (alert/prompt/confirm) are not shown from window.unload handlers when the app window is being closed

Status: RESOLVED WONTFIX

(Core :: DOM: Events, defect, P5)

Description

[Alfredo Fernández Díaz]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; es-ES; rv:1.8.1.19) Gecko/20081212 SeaMonkey/1.1.14 (PmW)
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

When a tab containing a document is closed, any window.unload events registered are triggered, as it should.

When the whole application is closed, these events are not fired, which will cause problems with any scripts that do things 'on exit'.


Reproducible: Always

Steps to Reproduce:
1. Load the example URL in a tab; see the alert message: "Window loaded!"
2. Close the tab; see the alert message: "Unloading window!"
3. Load the example URL again, see the same alert message as in step #1
4. Close or exit the application (Close button or File->Quit). No alert message like in step #2 will pop up.

Actual Results:  
No 'unloading window' message is shown upon application exit, but it is when a tab is closed.


Expected Results:  
The same message 'unloading window' should be shown when a tab is closed as upon application exit.

Verified on Windows and OS/2; FX versions: 4.0 and 4.0.1; SeaMonkey 2.1b3 exhibits the same behaviour on both platforms as well.

Comment 1

[Alfredo Fernández Díaz]

Attachment: HTML container + JavaScript testcase

Comment 2

[Boris Zbarsky [:bzbarsky]]

> these events are not fired,

They're fired, and the JS runs.  You can verify this in various ways (e.g. by having that JS touch some state somewhere).

All you're seeing is that when a window is already closed an alert() that's supposed to have that window as a parent can't be shown... because its parent is gone.  

So as far as I can tell, this bug is invalid.

Comment 3

[Alfredo Fernández Díaz]

(In reply to comment #2)
> > these events are not fired,
> 
> They're fired, and the JS runs.  You can verify this in various ways (e.g. by
> having that JS touch some state somewhere).

No need; if you say the JS runs, I'll believe you.
 
> All you're seeing is that when a window is already closed an alert() that's
> supposed to have that window as a parent can't be shown... because its parent
> is gone.  

OK, except that bits involving user input ("confirm" dialog boxes to save data, for example) are not shown either, which can still cause problems.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I think that if the user is quitting the app showing a confirm prompt would be totally broken....

Comment 5

[Boris Zbarsky [:bzbarsky]]

Of course it might also be that we're just showing them as tab-modal and then the whole window dies.

Comment 6

[Alfredo Fernández Díaz]

I might coincide with that were it not the case that too many people are used to close applications, then get a confirm prompt to save their data when they haven't done it manually.

[Which is why we have a checkbox to decide whether user confirmation is needed to close several tabs at once, etc.]

If a user doesn't bother to save his data and closes an application, I think the most sensible thing to do is try and warn him, or get a confirmation. Current behavior prevents this simple procedure that used to work in the past.

Comment 7

[Boris Zbarsky [:bzbarsky]]

When did it work?  I just tried Firefox 2, 3.5, 3.6, and 4 (on Mac) and none of them show the alert on the attached testcase when closing the browser window.

Firefox 3 tries to show it and ends up in a state where the app can't quit.

Comment 8

[Alfredo Fernández Díaz]

(In reply to comment #7)
> When did it work?  I just tried Firefox 2, 3.5, 3.6, and 4 (on Mac)
> and none of

My main browser is

Mozilla/5.0 (OS/2; U; Warp 4.5; es-ES; rv:1.8.1.19) Gecko/20081212 SeaMonkey/1.1.14 (PmW)

and it works.

I don't bother to check new versions thoroughly unless I'm planning to migrate, thus I don't know when it 'stopped' working.

Comment 9

[Boris Zbarsky [:bzbarsky]]

It "working" may be OS-dependent...

Comment 10

[Justin Dolske [:Dolske]]

I suspect this will end up WONTFIX anyway. There are existing bugs on disabling the ability to show modal prompts from certain events (like unload) because they're commonly used to abuse/annoy users. Better to use onbeforeunload to warn the user something is unsaved, and give them a chance to cancel closing the page.

Comment 11

[Alfredo Fernández Díaz]

(In reply to comment #9)
> It "working" may be OS-dependent...

I kind of expected that reply... ;(

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19) Gecko/20081204
SeaMonkey/1.1.14

displays the dialogs upon application exit as well, and apparently exits without crashing :)

Comment 12

[Alfredo Fernández Díaz]

(In reply to comment #10)
> I suspect this will end up WONTFIX. There are existing bugs on disabling
> the ability to show modal prompts from certain events (like unload) because
> they're commonly used to abuse/annoy users. Better to use onbeforeunload to

It can't be that hard to add some checkbox to the settings dialog saying 'let websites show modal dialogs blah blah', just like there is for the 'close multiple tabs'. Another MS-invented event as an alternative? Not ideal, I'd say...

About the bug ending up WONTFIXed, I'm OK with that as long as I know what's going on and I have some place to direct irate users to :)

Comment 13

[Boris Zbarsky [:bzbarsky]]

beforeunload is implemented in all browsers and specified to fire before the page is going to go away.  It's there so you can ask for user confirmation and prevent the page unloading if the user says so.

unload means the page is going away, period; you can't usefully "save" things from there nor prevent the page going away.  So if your use case is as described in comment 6, you want beforeunload.

Comment 14

[Alfredo Fernández Díaz]

(In reply to comment #13)
> beforeunload is implemented
...
> unload means the page is going away, period;
...
> So if your use case is as described in comment 6, you want beforeunload.

I never needed to go as far as prevent the page from unloading, but it sounds you're right about onbeforeunload being a better place for that kind of stuff, and the switchover seems almost trivial. I doubt Opera likes this, but it always had problems with [un]load events.

Anyway, couldn't onbeforeunload be abused exactly in the same ways people say unload is being abused?

Comment 15

[Boris Zbarsky [:bzbarsky]]

"maybe".  There are some subtle differences....

Comment 16

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 17

[Andrei Purice]

Hey Alfredo,
Can you still reproduce this issue or should we close it?
When I close the tab and window I no longer see the message "Unloading window!" - might be that the entire functionality has been changed during this time.

Comment 18

[Alfredo Fernández Díaz]

Hi,
yes, apparently it's been long since closing a mere tab (as opposed to the last remaining tab or the application window) stopped triggering window.unload, so it no longer matters that it is not triggered when closing the application window either.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:kmag, since the bug has high severity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 21

[Kris Maglione [:kmag]]

This is not behavior that we want.