Open Bug 2034813 Opened 2 months ago Updated 1 month ago

session restore is unreliable and incomplete

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Version:
Firefox 150
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: resuna, Unassigned, NeedInfo)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:150.0) Gecko/20100101 Firefox/150.0

Steps to reproduce:

Closed firefox, re-opened it, and attempted to restore session

Actual results:

  1. Session restore was not available on many occasions.
  2. Session restore restored an old state that did not reflect the state of the session when closed.
  3. When the last session was not available, there was no UI to attempt to restore from a previous saved session.

Expected results:

  1. Even after a force quit, and definitely after closing the browser cleanly, a recent session SHOULD always be available to restore.
  2. when closing cleanly, the restored session MUST EXACTLY reflect the state of the browser when closing.
  3. If after everything the last session state is corrupted, you MUST provide an interface to attempt to restore one of the older saved sessions without faffing around in the profile.
  • SHOULD and MUST are used as in RFC2119

Previous bug that was closed without fixing the problem: https://bugzilla.mozilla.org/show_bug.cgi?id=1199223

In addition, it would be nice if a dialog came up reflecting the status of the restore in progress, since Firefox will often just sit there for up to a minute apparently doing nothing befpre starting the restore, and may pause during the restore with no indication that the process is not complete.

The Bugbug bot thinks this bug should belong to the 'Firefox::Session Restore' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Session Restore

And... I just had to restore my session, and it restored my session to the state it was in over a week ago, I know this because it had pages that I had closed after cleaning up my badly-restored session back when I originally filed this bug open again.

Is there a way to explicitly force it to take a new snapshot of your session state?

Hi Peter da Silva, that sounds very frustrating. Could you attach any recent session restore logs from your profile directory? They should be in a sessionstore-logs directory in your profile directory (the location is linked in the about:support page).

Do you use any add-ons that interact with session restore? Do you have a large number of tabs, windows, etc.?

It's very odd to hear that it restored to a session a week old -- usually, the session should be no more than 15 seconds out of date.

OK, that's interesting, it says

1777663060513 SessionStore WARN SessionWriter.write, Caught exception:: NotAllowedError: Could not move .../Library/Application Support/Firefox/Profiles/....default/sessionstore.jsonlz4' to .../Library/Application Support/Firefox/Profiles/....default/sessionstore-backups/previous.jsonlz4' (NS_ERROR_FILE_ACCESS_DENIED) No traceback available
1777663060546 SessionStore ERROR Could not write session state file : NotAllowedError: Could not move .../Library/Application Support/Firefox/Profiles/....default/sessionstore.jsonlz4' to .../Application Support/Firefox/Profiles/....default/sessionstore-backups/previous.jsonlz4' (NS_ERROR_FILE_ACCESS_DENIED) No traceback available

(account and profile names elided)

The dates on the sessionstore files themselves:

-rw-r--r--@ 1 ... staff 2754434 Mar 27 16:50 sessionstore.jsonlz4
-rw-r--r--@ 1 ... staff 2583516 Apr 24 08:23 sessionstore.jsonlz4.tmp

% ls -ltr sessionstore-backups/
total 52880
-rw-------@ 1 ... staff 25700 Aug 12 2017 upgrade.js-20170809080250
-rw-------@ 1 ... staff 96211 Aug 18 2017 upgrade.js-20170814073321
-rw-------@ 1 ... staff 193006 Aug 31 2017 upgrade.js-20170824053838
-rw-------@ 1 ... staff 428634 Sep 29 2017 previous.js
-rw-------@ 1 ... staff 676229 Oct 3 2017 recovery.bak
-rw-------@ 1 ... staff 676218 Oct 3 2017 recovery.js
-rw-r--r--@ 1 ... staff 2774902 Mar 28 06:10 previous.jsonlz4
-rw-r--r--@ 1 ... staff 2774902 Apr 18 14:48 upgrade.jsonlz4-20260403140140
-rw-r--r--@ 1 ... staff 2774902 Apr 24 08:26 upgrade.jsonlz4-20260415192539
-rw-r--r--@ 1 ... staff 2774902 May 1 14:17 upgrade.jsonlz4-20260427013024
-rw-r--r--@ 1 ... staff 6926034 May 4 12:41 recovery.baklz4
-rw-r--r--@ 1 ... staff 6926003 May 4 12:41 recovery.jsonlz4

Permissions are randomly 600 or 644 so I'm guessing umask was randomly different as they were created. But that shouldn't cause a problem if Firefox is running as me. Some Apple gatekeeper style nonsense could be happening.

Yes, I have a huge number of tabs and windows open, which is why I care. :)

Same error message over and over again.

Won't let me create an attachment, logs here: https://github.com/resuna/junk/blob/main/error-sessionrestore.tgz

Ack, that's really strange.

All of the files with 600 are using the older session file format. If you no longer need those, you can safely delete them since Firefox should no longer be reading/writing them.

It looks like all of the current session file format files have consistent ownership and permissions. Firefox seems to have no trouble writing upgrade.jsonlz4* files, recovery.jsonlz4, recovery.baklz4. previous.jsonlz4 and sessionstore.jsonlz4 and sessionstore.jsonlz4.tmp all have the same permissions, but their timestamps are anomalously out of date.

https://searchfox.org/firefox-main/rev/a353242aeafd56b2c21a2c0672ecb51ea1b81142/browser/components/sessionstore/SessionWriter.sys.mjs#189-193 is where the sessionstore file gets renamed to the previous file on startup. Since that's failing, it looks like the outdated sessionstore.jsonlz4 is staying in place. If sessionstore.jsonlz4 exists on Firefox startup, we will automatically restore from that, because if it exists, it's always presumed to be the session file written successfully on the previous Firefox shutdown. We agree that it would be better to give users explicit options for which file to back up in case something goes wrong -- currently, you have to read https://support.mozilla.org/en-US/kb/how-restore-browsing-session-backup, and while that may help most people, there are edge cases where those directions could lead to not restoring the user's ideal session.

There isn't a way to force a snapshot of current state, but we do write the current session data every 15 seconds or so into recovery.jsonlz4. It looks like that process is working correctly based on its timestamps, but unfortunately, if you restore "successfully" into an outdated session, then the recovery file will quickly be replaced with the snapshot of the session you're running.

It looks like upgrade.jsonlz4-20260427013024 is the latest session file that looks complete based on its file size. I would expect that shutting down Firefox, copying upgrade.jsonlz4-20260427013024 to overwrite sessionstore.jsonlz4, and starting Firefox should restore that May 1 session. If there are still file access problems with sessionstore.jsonlz4 and/or previous.jsonlz4, then unfortunately I would expect you to run into the same problems again. :(

I'm not sure how to diagnose the file access problems because the permissions from your ls look fine. Do you have any scripts, apps, or other processes that you may have set up before to interact with/back up your session files? I'm not familiar enough with macOS file system internals to know whether an EACCES (converted to the NS_ERROR_FILE_ACCESS_DENIED error code by Firefox) could have a cause other than file perms.

I do not run any scripts to interact with anything in Firefox and the only installed and enabled extension is Firefox Relay which I don't use.

Apple has no end of layers of security theater paper-mache-ed over the UNIX permission system, both at application level and at the file system level, with delightful homespun names like Quarantine. I wish I could just disable them all.

The severity field is not set for this bug.
:sclements, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(sclements)

One problem seems to be some kind of wacky Apple specific limitation on the file it was moving, not the destination. Unix permission seemed clean but moving it failed. I have removed the file with rm -f and hopefully that will fix it. Timestamps on files seem to be saner since I did that, but I have not tested it by fire.

I hope that works! Please let us know whether that seemed to work. And if it recurs, that may point to Firefox writing the file with unexpected permissions. We can refer this bug to the macOS integration side of things if we can narrow it down.

Flags: needinfo?(sclements)

The severity field is not set for this bug.
:jwalker, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(jwalker)
Flags: needinfo?(jwalker)

The severity field is not set for this bug.
:sthompson, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(sthompson)

I had an issue recently where it seems that Firefox was closed incorrectly by KDE upon logout. Unfortunately this meant I lost some of my windows because the old ~/.mozilla/firefox/jx400l3x.default-esr/sessionstore-backups/previous.jsonlz4 had the erroneous session in it. I would suggest a backuo of the previous previous.jsonlz4 be stored as previous.baklz4 .previous.jsonlz4

(In reply to Reuben Peterkin from comment #16)

because the old ~/.mozilla/firefox/jx400l3x.default-esr/sessionstore-backups/previous.jsonlz4 had the erroneous session in it. I would suggest a backuo of the previous previous.jsonlz4 be stored as previous.baklz4 .previous.jsonlz4

should have been:
because the ~/.mozilla/firefox/jx400l3x.default-esr/sessionstore-backups/previous.jsonlz4 had the erroneous session in it. I would suggest a backup of the previous previous.jsonlz4 be stored as previous.baklz4 /

You need to log in before you can comment on or make changes to this bug.