sessionstore.jsonlz4 at the main level will only be there when Firefox is closed, so you can check whether this file gets created and has your last session.

Are you using "Show my windows and tabs from last time" as the startup setting as that is safest when you experience crashes ?

• Settings -> General -> Startup

Use one of these to close Firefox if you are currently doing that by clicking the close X on the Firefox Title bar, especially if you have multiple windows open to prevent losing tabs in unnoticed windows.

• "3-bar" menu button -> Exit (Power button)
• Windows: File -> Exit
• Mac: Firefox -> Quit Firefox
• Linux: File -> Quit

You will normally find these files in the sessionstore-backups folder:

• previous.jsonlz4 (cleanBackup: copy of sessionstore.jsonlz4 from previous session that was loaded successfully)
• recovery.jsonlz4 (latest version of sessionstore.jsonlz4 written during runtime)
• recovery.baklz4 (previous version of sessionstore.jsonlz4 written during runtime)
• upgrade.jsonlz4-<build_id> (backup created during an upgrade of Firefox)

You can copy a file from the sessionstore-backups folder to the main profile and rename the file to sessionstore.jsonlz4 to replace the current file with Firefox closed.

• make sure to backup the current sessionstore.jsonlz4

You can look at this tool to inspect a compressed jsonlz4 sessionstore file. This tool works locally, no uploading done.

• https://www.jeffersonscher.com/res/scrounger.html

after a normal close of firefox, there is still no sessionstore.jsonlz4 in the main level (or anywhere else). but other files (like storage.sqlite, sessionCheckpoints.json, ...) are created with the exact timestamp of closure. - yes, "Show my windows and tabs from last time" is checked in the settings - yes i have multiple windows and i always close by: "3-bar" menu button -> Exit (Power button)

ok now i discovered: - while i can create/move/modify files within the /sessionstore-backups/ folder, there seems to be a write-protection on that folder (windows explorer -> right click -> properties -> Attribute: write-protection) - if i uncheck this box, the files recovery.jsonlz4/baklz4 update frequently - but if i again open this dialogue, this checkbox is checked again (partly checked as rectangle) - so not sure if this setting will stay persistently

now after a few hours, the frequent update of the files recovery.jsonlz4/baklz4 stops. even if i remove the partly-checked checkbox from write-protection for the whole folder+files again, the update does not resume.

I remember one thread from a few years ago where a user's recovery.jsonlz4 stopped getting updated at some point during a session (and also its backup file, recovery.baklz4). I don't think we discovered the cause of this problem.

Next time you notice this problem has started:

If you try a manual session export, can Firefox generate and save it successfully? You can do that by running a script in the Browser Console (Ctrl+Shift+J). Here are some scripts to test:

(1) Script to generate a full session history file in JSON format

https://gist.github.com/jscher2000/d7c77f90bde6f37f526faa56c6a2b19e

This format is restorable with various renaming gymnastics. You can check its completeness by converting it to an HTML list of windows and tabs using my tool at https://www.jeffersonscher.com/ffu/scrounger.html.

(2) Script to export tab titles and URLs to a CSV file

https://gist.github.com/jscher2000/623eb8e9fb0167a139e2c089523f83c9

This is meant for reference, not restoration, but may be useful for a quick spot-check.

thanks for the hint with the Browser Console! this reveals the problem: (without running your script) "Could not write session state file out of memory"

any idea how to solve this?

running this code: https://gist.github.com/jscher2000/d7c77f90bde6f37f526faa56c6a2b19e

brings a "Uncaught out of memory" error in the console

Please see next reply

That's not good, but I'm relieved that unlike many other "out of memory" situations, it didn't cause Firefox to crash immediately. Can you close other programs running on the system to free up memory and see whether that makes any difference in running the script(s) or in Firefox resuming writing to recovery.jsonlz4?

If you can get recovery.jsonlz4 updated, then it probably would be a good idea to restart Firefox. You can use the third button on the right side of the Troubleshooting Information page, under the heading "Try clearing the startup cache".

Ref. Use the Troubleshooting Information page to help fix Firefox issues

Okay, after a little further research... your error message (above) --

-- is somewhat similar to this one that is on file for bug #1691498 (attached; filed against Firefox 84):

The discussion in that bug refers to the session data being too large, rather than system memory not being available. So the description in the Browser Console probably isn't accurate.

The quickest way to reduce the size of session data is to stop saving so much session data. There are a few different options for this:

(1) Save less back-forward history per tab

During your session, Firefox saves up to 50 back-forward pages per tab by default. For session restore purposes, this is reduced to 10 by default. If you don't need so much back-forward history in a restored session, you could reduce that value to, say, 5 pages. I'll mention how later in this post.

(2) Save fewer closed tabs per window

The default value is to save up to 25 closed tabs per window. If you find yourself accidentally closing a lot of tabs at once (other than by closing the whole window), you might not want to reduce this value. However, if you could get by with saving a smaller number, I'll mention how to try this later in this post.

(3) Save fewer closed windows

By default, Firefox only saves the last three closed windows. I do not recommend reducing this number.

(4) Stop saving cookies, form data, and page state (or possibly shrink form data)

In order to restore a page with the greatest fidelity, Firefox saves session cookies set by the page, form data (if the page allows caching), and state details such as your last scroll position. If you are restoring pages and do not want to have to sign in again, turning off this data will be a problem for sites that do not set persistent cookies. There isn't a good way to specify which sites will have saved data and which will not, so you get to choose between saving for all, saving for http but not https, or not saving for any. I'll give the details below.

If there are any other options, they are not coming to mind this morning.

Modifying What is Saved in Session State

(1) In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button accepting the risk.

More info on about:config: Configuration Editor for Firefox. The moderators would like us to remind you that changes made through this back door aren't fully supported and aren't guaranteed to continue working in the future.

(2) In the search box in the page, type or paste sessionstore and pause while the list is filtered

Back-Forward History

(3) Double-click the browser.sessionstore.max_serialize_back preference to display an editing field, and change the value to a smaller value, such as 5, then press Enter or click the blue check mark button to save the change.

(4) Double-click the browser.sessionstore.max_serialize_forward preference to display an editing field, and change the value to a specific value, such as 5, then press Enter or click the blue check mark button to save the change.

Note: for both of those preferences, the value -1 means "everything"

Firefox should display a very long list of preferences.

Closed Tabs

(5) Double-click the browser.sessionstore.max_tabs_undo preference to display an editing field, and change the value to a smaller value, such as 15, then press Enter or click the blue check mark button to save the change.

Cookies, Form Data, and Page State

I just discovered the two preferences in #6 and I don't know whether they would be a useful thing to try changing before trying #7:

(6) By default, Firefox will save up to 2,097,152 characters of data per form field [browser.sessionstore.dom_form_limit], up to a maximum of 52,428,800 characters of form data per site [browser.sessionstore.dom_form_max_limit]. If any sites were to actually consume that much of your session history, it could be a factor in tipping you over into this issue. I haven't researched the reason behind these values, so I don't know how safe it is to reduce them; many forms contain hidden fields used to maintain continuity, so what you see on the screen may be only the tip of the iceberg. Still, these numbers seem staggeringly high...

(7) Double-click the browser.sessionstore.privacy_level preference to display an editing field, and change the value as desired, then press Enter or click the blue check mark button to save the change. The valid values are:

• 0 => Save for all pages
• 1 => Save for http: addresses but NOT https: addresses
• 2 => Do not save for any pages

I don't know which of those preference changes will take effect immediately (i.e., at the next interval for updating the file) and which might not take effect until your next session. If you try any of these changes, please let us know what you find.

thank you very much for your detailed answer! - i tried everything you mentioned (1-7), waited enough time, but still no autmatic update of the files, nor a manual update via brwoser console and the script, still the same error in the console. - also i closed a lot of firefox windows (from previously ~30 to 15) and some tabs inside (from ~10 per window to ~3 per window) - i also used the feature of about:unloads - after all, the used memory (viewed in task-manager) was reduced from ~ 6GB to 1.5GB of all firefox processes

but sadly still no success.

ok so i closed and restarted firefox, - i got all my 32 windows with many tabs back - but only 1.7GB of used memory - i don't know why there are 32 windows but only 25 processes - and there has been 25 processes before where i only had ~15 windows - and the recovery.jsonlz4 has updated once! but not frequently - and manual running the script in console brings again the out of memory error

That's interesting, that Firefox picked up on enough changes at shutdown to be able to save your session (or at least a snapshot of your session from when more windows were open), but not during your browsing. I don't know why that would be.

The number of processes created is related to the number of different sites open, so when 32 active tabs are restored, it's possible that some of them can share the same process. To see which tabs are in which processes, you can use the internal task manager page at about:processes (in a later version. Shift+Esc opens that page, but not in Firefox 102).

ok what i did now: - i installed firefox portable 64bit - tried to transfer my windows&tabs, which is not possible as long as there no sessionstore or up-to-date recovery.jsonlz4. -> so this firefox is empty so far, but: - i found a button "use additional profile" in about:profiles - which opens my 32 windows and many tabs inside this 64bit installation (checked through '3 lines button' -> "about firefox". don't know how this is possible), with all addons from the 32bit installation - here the frequent update of recovery.jsonlz4 and also the creation of the sessionstore.jsonlz4 file (in the original profile folder from the 32bit installation!) works!

but from now on, i am not able to launch the 32bit firefox with that profile again:

The PortableApps build of "Portable Firefox" can use profiles saved by regular Firefox? I had no idea. What version -- is it also Firefox 102.4.0esr, or is it Firefox 109?

the latest Firefox portable 109.0 64bit

Oh no. Opening a profile updates all the files to the formats used by the build that opened it. You can try using the older version to access the upgraded profile, but because there is a large gap between Firefox 102 and Firefox 109, there is a higher risk of data loss in this situation than the more typical scenario of rolling back by one version.

You definitely should make a backup of the "root" profile folder before trying a downgrade. See: Back up and restore information in Firefox profiles

Then see the "What happens to my profile if I downgrade to a previous version of Firefox?" section of this article: Dedicated profiles per Firefox installation.

ok thank you jscher2000 for your help! i guess, there will be no real solution for my problem on 32bit firefox. so i am fine with the 64bit "solution" (transfer of my profile to 64bit firefox installation) and would mark this as solution.