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

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

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.

Comment 1

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(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!

Comment 2

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

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.

Comment 3

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

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

[era+mozilla]

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.

Comment 5

[Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)]

Seems like this needs UX love... if not usability love.

Comment 6

[era+mozilla]

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.

Comment 7

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(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

Comment 8

[mjbauer]

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

[Jesse Ruderman]

That's bug 495123, not this bug.  (Next time, you can use "Undo Close Window" at step 5, by the way.)

Comment 11

[Andrei Purice]

Following the reporter's steps I am able to confirm that the issues doesn't happen anymore on MacOS 10.15 on any of the current versions of Firefox Nightly 87.0a1 (2021-02-18), beta 86.0 and release 85.0.2. Tabs are restored automatically after re-opening Firefox (for trigger I have used about:crashparent).

Closing this issue as Resolved > Worksforme.
Feel free to re-open or file a new bug if this issue reoccurs again.