380862 - Closing "Restore Previous Session" dialog loses session restore data by starting a new session rather than stopping startup and exiting Firefox

Status: VERIFIED INVALID

(Firefox :: Session Restore, defect)

Description

[Bartosz Kosiorek]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)

From the version 3.0, Firefox automaticly remeber opened tabs and websites, when webbrowser is unexcpected closed.
When You try open Firefox again, webbrowser display "receive previous session" dialog.
And there is a bug:
When You click "cross" (which should close Firefox), all tabs and websites will be lost :-( 
Firefox runs with default homepage.


Reproducible: Always

Steps to Reproduce:
1. unexcpected close Firefox
2. Run Firefox (should display "receive previous session" dialog)
3. Try to close this dialog by press "cross" at the top right corner of the window
Actual Results:  
All tabs and websites which should be written will be lost.

Expected Results:  
the cross should close Firefox, but without loose all previous tabs.

Comment 1

[Bartosz Kosiorek]

Sorry. From the version 2.0, Firefox automaticaly remeber opened tabs and websites. :-P

Comment 2

[Adam Guthrie]

IMO, this is WONTFIX. When you're presented dialog, you have to choose one of the available choices; you can't just exit and and expect something else to happen.

Comment 3

[Simon Bünzli]

Quite certainly ain't WONTFIX: canceling the dialog (by closing it) should be as harmless as possible. Currently you get potential dataloss instead.

At least, closing the dialog through the window manager should make Firefox resume the previous session - canceling Firefox' startup would be another alternative. Unfortunately the latter is impossible as long as were using the stock nsIPromptManager dialog...

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Confirmed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.4pre) Gecko/20070516 BonEcho/2.0.0.4pre ID:2007051603

I'm not able to find another bug with similar issues.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Same for Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a5pre) Gecko/20070515 Minefield/3.0a5pre

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

The confirmex dialog always returns 1. This is covered in bug 345067. That's why always "Start new session" is used when the x button is pressed:

http://lxr.mozilla.org/seamonkey/source/browser/components/sessionstore/src/nsSessionStartup.js#290

If this issue should be fixed for the 1.8 branch we have to flip both buttons. I don't think that this is nice but the only way. Otherwise we have to wait until bug 345067 is fixed on trunk.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Attachment: Possible fix by flipping the buttons

Comment 8

[Simon Bünzli]

(In reply to comment #7)
> Possible fix by flipping the buttons

Now, that's calling for dataloss: moving the default button to where usually cancel resides, while "Start New Session" already has quite some attention due to its size (see bug 346264). This bug may look dangerous, I however doubt that people are hitting it that often - at least much less often than they would start a new session in your proposed scenario.

If you want to fix this issue, I'd rather see a new basic dialog for this specific issue which will simply shut down Firefox as instantly as possible when closed the way implied by this bug (such a dialog can easily be hooked into SessionStore through browser.sessionstore.restore_prompt_uri). Much less risky overall.

Comment 9

[Mike Connor [:mconnor]]

Way too late to block 2.0.0.4, not sure why, even if we decide to change this interaction, we'd want to immediately block on something that's been in builds for nearly a year with very little negative feedback.

1) Why is the assumption that closing the dialog will close the app?  I think that's a bad assumption on the user end, and I'm not going to spend a lot of time trying to address that.

2) Fixing this with new strings is more or less a non-starter at this stage, unless we have more than an isolated bug report indicating this is a significant problem and not an edgecase expectation.  It'd be nice if we could force the user to take one of the two actions.

3) flipping the buttons is a non-starter.  I'm not sure we need to do anything here, but it looks like trunk only at this point.

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to comment #9)
> 1) Why is the assumption that closing the dialog will close the app?  I think
> that's a bad assumption on the user end, and I'm not going to spend a lot of
> time trying to address that.

I think the better question is why would one assume that dismissing a dialog would cause the application to make an ill-informed choice for the user?  

There are certainly good examples where closing a dialog behaves properly:

* thunderbird, compose a message, click X without sending the message, save dialog pops up, click X, dialog dismissed and returns to compose window (no data loss)
* firefox (with tab close prompt enabled), multiple tabs, click X, "confirm close" dialog pops up, click X, dialog dismissed and returns to window with tabs(no data loss)


> 2) Fixing this with new strings is more or less a non-starter at this stage,
> unless we have more than an isolated bug report indicating this is a
> significant problem and not an edgecase expectation.  It'd be nice if we could
> force the user to take one of the two actions.

If doing bug 345067 isn't a viable solution (it hasn't made any progress) then forcing a choice (and disallowing cancellation of the dialog via clicking "X") seems reasonable given the consequence is dataloss.


> 3) flipping the buttons is a non-starter.  I'm not sure we need to do anything
> here, but it looks like trunk only at this point.

Actually it also happens in FF2. (this doesn't make it any less painful)

Comment 12

[Wayne Mery (:wsmwk)]

another possible choice (but affects strings) is the example of FF2 installer. click X during install and it asks, "Are you sure you want to quit Mozilla Firefox Setup?"

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Any change to get it on the radar? Normally it will happen only once for an user but then it's hard to loose all the opened tabs!

Comment 14

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

This will not block the final release of Firefox 3.

Comment 15

[KBJ]

Guess I'm not normal, this has happened to me more than once.  Last night I was tired and clicked "X" to close the window, and it trashed all my previous settings.

Cannot a dialog "Are your sure?" be done, or just exit without changing the list of saved tabs & windows?

Lacking any changes to this, is there a workaround if someone goofs?  I'm using Windows-Vista which lets me restore previous versions of files; is there some file whose previous version could be restored to give me another chance to restore my previous session?

I consider this very important!

Comment 16

[Simon Bünzli]

Resolving as INVALID since the Session Restore prompt was removed in bug
448976. Should you still manage to lose a session by clicking the window's close button [X], this will most probably be due to bug 454466.

Comment 18

[codywohlers]

this affected me too. RIP session and workflow