1464685 - Firefox fails to load large session store

Status: UNCONFIRMED

(Firefox :: Session Restore, defect, P4)

Description

[tobbez]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180524181234

Steps to reproduce:

1. Firefox crashed (not what this report is about)
2. When starting up again, Firefox failed to properly load the session restore data in the about:sessionrestore tab, likely because that data was too large
3. I decompressed sessionstore.jsonlz4 and extracted the formData from the about:sessionrestore tab in it and saved that as sessionstore.js.
4. Tried to start Firefox using the resulting file, but it (silently) failed to load the session and just started an empty session (re-compressing as to jsonlz4 did not make difference).
5. Stripped some extension cache data stored by the Tree Style Tab extension, see issue filed against TST for details (https://github.com/piroor/treestyletab/issues/1907 "TST bloats Firefox session store file"). In short, this decreased the uncompressed size of sessionstore.js from 257MiB to 38MiB.
6. Tried to start Firefox using the resulting file, and it worked.

In addition, the session restore data that actually was in the file was ~1.5 months old (despite being written recently), so while just a guess, it seems like Firefox might have issues writing session store files that are too large as well.


Actual results:

Firefox discarded my session.


Expected results:

Firefox should have loaded the session without issue.

Note that while I filed an issue against the TST extension for bloating the file size of the session store, Firefox being unable to load it properly should still count as a bug.

Comment 1

[John Drinkwater (:beta)]

Great to see this bug, had this issue a few weeks ago after a crash, but have not yet reproduced Firefox creating a file it couldn’t read as it stopped writing above the size it could read Bug 1472470.
Maybe while it is in the state being unable to write because of too much data, and then the browser is closed and it writes a file too big that it otherwise would avoid?

Comment 2

[Mihai Dobrescu]

Since version 67 I have a similar issue, it partially restores the session.
It is so annoying!

Comment 3

[Mihai Dobrescu]

Now has become a pain. It seems to be frozen to some snapshot. Everytime I close and open Firefox it restores a specific set of tabs, never the last ones. Did not matter I have deleted the session store files and set a session store file, it will open those tabs and that's it, never the files, seemingly.
It is a major issue now!

Comment 4

[jscher2000]

(In reply to Mihai Dobrescu from comment #2)

Since version 67 I have a similar issue, it partially restores the session.

Hi Mihai, first, please back up all recent files from the sessionstore-backups folder in your profile. There may be tabs in recovery.baklz4, previous.jsonlz4, or an upgrade.jsonlz4-timestamp file to recover. https://support.mozilla.org/kb/profiles-where-firefox-stores-user-data

Second, there are other bugs more specific to Firefox 67 to review. I don't see a clear prescription for how to avoid the problem, but using Firefox 68 beta might help.

• bug 1553413
• bug 1553417 (comment 22 indicates a possible problem having about:config open)

Comment 5

[Mihai Dobrescu]

Hi, tried some fixes, the recovery doesn't help, but the problem lies in some other place, seemingly.
No matter how many attempts to cleanup and recover I did manually, it simply did not pass a specific recovery point in time, meaning it always recovered the tabs before a specific date.
Anyway, I have performed a Piriform CCleaner cleanup with Firefox closed. I do this regularly, with clearing the internet cache set (and download history, but I think it is irrelevant this one). After this, Firefox restores the tabs again. I have also Avast Premier with everything active, including firewall asking for any new rule change, so I don't think malware is involved. Malwarebytes did not find anything, so I guess it's related to the filesystem or files structures on Firefox part, that went messed up or some file access that was not right. I'm out of ideas.

BTW, I know that a bug is not treated until there is time to do it, so it stays in a queue for a long time in some cases, so no excuse is needed.
I hope you understand, sometimes is hard to provide a clue. Regards.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 14 votes.
:dao, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 7

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 8

[Wayne Mery (:wsmwk)]

Does this still reproduce for you when using a current version?

I also have TST, have a large sessionstore, and several years ago was seeing problems. But haven't encountered problems in the last three years.

Comment 9

[tobbez]

Attachment: firefox-bloat-session-store.zip

Can't provide feedback on the TST-specific issue, as I no longer use TST. The TST author also made some changes that mitigate this issue (see commits referencing https://github.com/piroor/treestyletab/issues/1907).

However, the underlying issue in Firefox is still present:

1. Open a clean Firefox profile
2. Enable "Open previous windows and tabs" in about:preferences
3. Install the attached extension (firefox-bloat-session-store.zip)
4. Activate the extension's browser action (extension menu -> bloat-firefox-session-store)
5. Wait until the extension has finished opening tabs
6. Exit Firefox
7. Start Firefox again
8. Firefox fails to load the session store

Confirmed on Firefox 110.0b6.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:dao, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.