1891433 - Session not restored, "state.windows[0] is undefined" logged in the console

Status: NEW

(Firefox :: Session Restore, defect, P2)

Description

[Sarah Clements [:sclements]]

Started Firefox Nightly after starting my mac, and instead of restoring my session I have a new session created and no option to restore the previous session. The "Open previous windows and tabs" preference is still selected, and I saw this error in the console:

SessionStore: The session file is invalid: TypeError: can't access property "hidden", state.windows[0] is undefined SessionStore.sys.mjs:1162:19
    initSession resource:///modules/sessionstore/SessionStore.sys.mjs:1162
    onBeforeBrowserWindowShown resource:///modules/sessionstore/SessionStore.sys.mjs:2005

And this is where that error is logged in initSession. Interestingly, I still have all of my recently closed tabs and recently closed windows restored, so it seems to be the action of actually restoring the session in the last step that might be broken.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

We had the exact same problem yesterday on MacOS when Firefox was started after the machine got shutdown the evening before. The complete session was lost and a new one was created. There is no way for a normal user to actually restore the session via the UI in Firefox.

Here the content from the error-sessionrestore log:

1715752038799	SessionStore	DEBUG	Can't read session file which doesn't exist: clean
1715752038869	SessionStore	DEBUG	Successful file read of recovery file
1715752038869	SessionStore	DEBUG	Completed SessionFile.read() with result.origin: recovery
1715752038869	SessionStore	DEBUG	isAutomaticRestoreEnabled: true
1715752038869	SessionStore	DEBUG	Previous shutdown ok? true, reason: final-state-write-incomplete
1715752039339	SessionStore	DEBUG	initialState contains 0 pinned tabs
1715752127106	SessionStore	DEBUG	initSession willRestore: true, SessionStartup.sessionType: 2
1715752127106	SessionStore	DEBUG	initSession, will autorestore
1715752127106	SessionStore	ERROR	The session file is invalid: : TypeError: state.windows[0] is undefined(resource:///modules/sessionstore/SessionStore.sys.mjs:1163:11) JS Stack trace: [e-mail]:1163:11
onBeforeBrowserWindowShown/<@SessionStore.sys.mjs:2035:35
1715752127107	SessionStore	DEBUG	Restored 0 closed windows
1715752127107	SessionStore	DEBUG	restoreWindows will restore 0 windows
1715752127107	SessionStore	DEBUG	sessionstore-windows-restored
1715752127130	SessionStore	DEBUG	All 0 windows restored

The workaround was to close Firefox and to manually copy the previous.jsonlz4 file from sessionstore-backups one level up as sessionstore.jsonlz4. Thankfully that one still had all the windows and tabs included.

Comment 2

[Sarah Clements [:sclements]]

Thanks for posting this. sfoster just added some additional logging and you posting this has made it more actionable for us. We'll get this prioritized. Do you close the browser/shut down your machine differently than you typically do?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Usually I instructed the person to exit Firefox first, but this time the machine was shutdown immediately. So maybe some invalid data was written to disk? That's hard to tell. But it also didn't happen again so far. If further details are needed I still have the database files around, but I cannot share regarding privacy. But I'm happy to run checks if I get the exact steps.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

And it happened again today. There is no sessionrestore.jsonlz4 file present in the profile directory and trying to restore ended up in a single window. And that even with manually copying the previous.jsonlz4 or restore.jsonlz4 files as sessionrestore.jsonlz4 to the profile's folder. After a couple of tries I noticed that not canceling the primary password prompt but actually entering the password allowed us to restore the session. Since when this is connected to each other?

Comment 5

[Sam Foster [:sfoster] (he/him)]

(In reply to Henrik Skupin [:whimboo][⌚️UTC+1] from comment #4)

And it happened again today. There is no sessionrestore.jsonlz4 file present in the profile directory

This is the expected consequence of the abrupt shutdown.

and trying to restore ended up in a single window. And that even with manually copying the previous.jsonlz4 or restore.jsonlz4 files as sessionrestore.jsonlz4 to the profile's folder.

If there's no state.windows[0] it looks like the recovery.jsonlz4 file is basically bogus. Clearly we need to find out why we wrote an essentially empty file. But also maybe we can catch this and return to the loop that attempts to find the more recent session file to restore from?

After a couple of tries I noticed that not canceling the primary password prompt but actually entering the password allowed us to restore the session. Since when this is connected to each other?

A good question! This is the first I'm hearing of the primary password prompt being a factor here. Do you have even incomplete STR? You said "a couple of tries" - what were you trying? And if you have that recovery.jsonlz4, I'd love to see it. Its basically a compressed JSON file with a weird header. There are some options in this post to unpack it. I'm assuming its only a few bytes in size? If not find me in matrix or slack and we can discuss options. Obviously, a session file can have lots of PII so I don't want you posting it here or sending it to me blindly without some information about what's in it.

Comment 6

[Sam Foster [:sfoster] (he/him)]

(In reply to Sarah Clements [:sclements] from comment #0)

Interestingly, I still have all of my recently closed tabs and recently closed windows restored, so it seems to be the action of actually restoring the session in the last step that might be broken.

This suggests the bogus recovery file and the console message might be a state we normally recover from. I'd still like to know what's going on there, but an answer there might not end up fixing :whimboo's bug.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: recovery.jsonlz4 with session data not written

(In reply to Sam Foster [:sfoster] (he/him) from comment #5)

A good question! This is the first I'm hearing of the primary password prompt being a factor here. Do you have even incomplete STR? You said "a couple of tries" - what were you trying?

With tries I actually meant that I copied the recovery.jsonlz4 file as sessionstore.jsonlz4 to the profile folder and started Firefox. I don't have minimal STR here but setting the primary password before the issue happens is probably a required step. So here in detail what I did:

1. Copied the file
2. Started Firefox and aborted the prompt for the primary password
3. Repeated steps 1 and 2 around two times
4. Did step 1 again, but then asked my partner to enter the primary password to not have to cancel the prompt
5. Surprisingly that worked out and the windows were restored.

And if you have that recovery.jsonlz4, I'd love to see it. Its basically a compressed JSON file with a weird header. There are some options in this post to unpack it. I'm assuming its only a few bytes in size? If not find me in matrix or slack and we can discuss options. Obviously, a session file can have lots of PII so I don't want you posting it here or sending it to me blindly without some information about what's in it.

Yes the recovery.jsonlz4 is in such a case only 1kB in size. I've just taken a look and it doesn't contain any private information so that I can upload it (see attachment). Not sure if that's helpful or not, but please take a look. In contrast the previous.jsonlz4 has still a size of 7.5MB. As you said I cannot just share this file but would have to prepare it before. So maybe you could have a look first if the recovery file shows some suspicious behaviors which might explain it already.

Comment 8

[Sam Foster [:sfoster] (he/him)]

So the recovery file basically has a clean/new session. Its one window with about:home and that's about it. If that session was restored it would appear as if no session was restored even if Session Restore thought it was successful. So I think if there's a bug here its when we write (or fail to write) to the recovery file. Or, as I mentioned, we could maybe recognize this as an essentially bogus recovery state and skip over it to restore the previous.jsonlz4 instead.

I'm hesitant to just paper over that crack though without understanding how we got into that state. I'll leave the need-info until I get a chance to try out some STR with primary password.

Comment 9

[Sam Foster [:sfoster] (he/him)]

Ok I think the primary password case is bug 1901899 - which has a patch and is making its way to release. I don't think that explains the original issue and we should at least add some more logging to the session writing end of things to know more about how we end up in a state where the recovery file is an empty session.