If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"Restore previous session" greyed out in menu after crash and "start new session"

NEW
Unassigned

Status

()

Firefox
Session Restore
--
critical
7 years ago
3 years ago

People

(Reporter: davedash, Unassigned)

Tracking

({dataloss, uiwanted, ux-undo})

Firefox Tracking Flags

(Not tracked)

Details

User-Agent:       Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

I accidentally hit start new session, and I thought I could restore it, by going to restore previous session.  This option was greyed out.

Reproducible: Always

Steps to Reproduce:
1. Get your browser to crash (I don't know how I do this)
2. Start new session
3. See that restore previous session is greyed out.
Actual Results:  
Option is greyed out

Expected Results:  
Option is available and I can restore my previous session.
Component: General → Session Restore
QA Contact: general → session.restore
(In reply to comment #0)
> Actual Results:  
> Option is greyed out

That is in fact how it works now.

> Expected Results:  
> Option is available and I can restore my previous session.

I like your idea. Based on bug 477322, you're definitely not the only one to accidentally hit that button & feel lost. Enabling this menu item in that case might help alleviate the "oh shit" feeling. Implementation gets a bit tricky, but I'm trying to avoid letting that get in the way of good ideas. Adding uiwanted to see what UX thinks here.

For future reference, if you accidentally hit "start new session" there, you can always press the back button to go back to the restore page. Dave, I think I just told you that in another bug but I'm bad with names. Sorry if I'm repeating myself!
Keywords: uiwanted
Yup, you mentioned that.

What is the "Restore previous session" supposed to be?  Sounds like I'm conflating session restore with some feature that's unknown to me.
Restore Previous Session was really implemented to complement getting rid of the quit dialog. We couldn't really get rid of that dialog without some way of allowing tabs to be recovered (assuming you didn't have it set to auto-restore). I hadn't taken into account the other potential use cases.

Comment 4

6 years ago
Here from related WONTFIX bug #666150.  As I found out by reading other related bugs, another workaround for users who already thought they had to live with the new session they didn't want, and hence cannot easily get "back", is to navigate to about:sessionrestore.

What does it take to get this to CONFIRMED state?  Why on Earth is this option greyed out?  To me, it seems like a serious issue, and an inconsistency to boot.
Seems like this needs UX love... if not usability love.

Comment 6

6 years ago
davedash: Can I help?  If so, how?  I'm not familiar enough with the code base to create patches, but I can reason about usability and expectations.
(In reply to comment #6)
> davedash: Can I help?  If so, how?  I'm not familiar enough with the code
> base to create patches, but I can reason about usability and expectations.

The relevant code is in a few places... https://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/src/nsSessionStore.js#317 is where the session file is read and we decide if we're going to show about:sessionrestore. https://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser-places.js#684 is where the menu item is enabled/disabled.

The content for about:sessionrestore is in https://mxr.mozilla.org/mozilla-central/source/browser/components/sessionstore/content/

Things get a little bit complicated here...
* app tabs are normally restored, except in the case of the about:sessionrestore appearing. The normal deferred session restore probably doesn't work quite right for this
* we want to make sure about:sessionrestore is closed if you do this
  - it behaves a bit outside of normal session restore so we don't want people to accidentally restore 2 sessions
* probably something else I'm forgetting

Updated

6 years ago
Keywords: dataloss, ux-undo
Severity: normal → critical

Updated

4 years ago
Blocks: 867085

Comment 8

4 years ago
Another use case for this one:

* Open a second window, because it's useful for me to have two windows side by side
* Forget that I opened the second window
* Close the main window, with all my tabs in it
* Discover the second window still open
* Swear a lot
* And, because this worked last few times I made this mistake: *close the second window* so I can use the "restore previous session" menu feature
* Restart Firefox
* Discover that "History->Restore Previous Session" is grayed out
* Try some other trickery with sessionstore.js/sessionstore.bak -- no luck
* Swear some more
* Add to this bug

What's the point of having "restore previous session" if it doesn't actually remember previous sessions, and let you restore it in case of error?  There used to be two previous sessions stored.  The most recent was the one with just the one tab left from the window I forgot -- not useful.  The next-most-recent had all my tabs from the previous start-up, and that was a whole lot better than nothing.

Comment 9

4 years ago
That's bug 495123, not this bug.  (Next time, you can use "Undo Close Window" at step 5, by the way.)
Duplicate of this bug: 867085
You need to log in before you can comment on or make changes to this bug.