405486 - if a page is disposed after handling onbeforeunload, continue with quit operation

Status: RESOLVED DUPLICATE of bug 449308

(Firefox :: General, defect)

Description

[Basil Hashem [:baz]]

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b2pre) Gecko/2007112604 Minefield/3.0b2pre

1. Open Zimbra (e.g. mail.mozilla.com) in a tab
2. Quit Minefield using Apple-Q
3. Zimbra's close tab-confirm dialog appears, click "OK"
4. Minefield doesn't quit
5. Press Apple-Q again to actually quit

Comment 1

[Josh Aas]

This needs to be a blocker for whatever component it ends up in.

Comment 2

[Basil Hashem [:baz]]

Here is another example where this is manifested.

1. Go into GMail
2. Create a message and start typing some content
3. Use Apple-Q to quit Minefield
4. Confirm OK on the dialog
5. Minefield doesn't quit

Comment 3

[:Gijs (he/him)]

Why was I CC-ed on this bug? Is it a regression from something I touched? I've been away from the appstartup quit mess for quite some time now, and something like this doesn't look like the kind of stuff which stays hidden for very long.

Comment 4

[Josh Aas]

I suggested that you be cc'd because you are the last person that I saw work with code that might be related.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

--> unspecified version, as it happens on trunk and on branch

I'm not sure where it needs to live, so leaving in Firefox::General, and at this stage of the game, I'm unwilling to block on a non-regression, but it would be really nice if we handled this better.

What seems to be happening is:

 - browser quit event is fired
 - all tabs get the window.close() event
 - any tab with an onbeforeunload handler catches the close event and fires its code
 - we stop the quit event

What we should be doing is pausing the quit event until we know the fate of that tab; if it continues to live, we should cancel the quit event, but if it goes away then we should keep going with the quit event.

From what little I know of the way events are handled, and because there's no way for onbeforeunload to report success/failure back to the browser, I suspect that this will be pretty difficult to get right without some timeout value -- which, sadly, could end up causing dataloss (ie: user quits, steps away, the onbeforeunload handler asks if they want to save before quitting, times out, user has now lost data)

Comment 6

[Honza Bambas (:mayhemer)]

Isn't this duplicate of bug 449308?

Comment 7

[Honza Bambas (:mayhemer)]

As I was working on bug 449308 with onbeforeunload, it seems that all problems described here were fixed with that bug.