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

UNCONFIRMED
Unassigned

Status

()

Core
DOM: Events
--
major
UNCONFIRMED
7 years ago
7 years ago

People

(Reporter: Alfredo Fernández Díaz, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
Created attachment 530324 [details]
HTML container + JavaScript testcase
> 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.
(Reporter)

Comment 3

7 years ago
(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.
I think that if the user is quitting the app showing a confirm prompt would be totally broken....
Summary: DOM in FX4 and SM 2.1b3: window.unload events are not triggered when application is closed → 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
Of course it might also be that we're just showing them as tab-modal and then the whole window dies.
(Reporter)

Comment 6

7 years ago
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.
Attachment #530324 - Attachment mime type: text/plain → text/html
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.
(Reporter)

Comment 8

7 years ago
(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.
It "working" may be OS-dependent...
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.
(Reporter)

Comment 11

7 years ago
(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 :)
(Reporter)

Comment 12

7 years ago
(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 :)
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.
(Reporter)

Comment 14

7 years ago
(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?
"maybe".  There are some subtle differences....
You need to log in before you can comment on or make changes to this bug.