Closed Bug 1730021 Opened 3 years ago Closed 3 years ago

Firefox does not restore session on restart

Categories

(Firefox :: Session Restore, defect, P1)

Product:
Firefox
Component:
Session Restore
Version:
Firefox 92
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
95 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- unaffected
firefox93 --- wontfix
firefox94 + verified
firefox95 + verified

People

(Reporter: david, Assigned: Gijs)

References

(Regression)

Details

(Keywords: dataloss, regression)

Attachments

(3 files)

Corrupted sessionstore.jsonlz4
5.90 KB, application/octet-stream
Details
Bug 1730021 - fix restoring sessions that closed all tabs, r?Standard8,dao
48 bytes, text/x-phabricator-request
Details | Review
Patch for beta
5.27 KB, patch
RyanVM
: approval-mozilla-beta+
Details | Diff | Splinter Review

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Open a few tabs: google, Reddit. Closed with ctrl-shift-q. Started Firefox again.

Actual results:

firefox opened up with only my homepage (Google) as a tab, losing the session data.

Expected results:

The same tabs that were open before closing should have been available on restart, as the setting to restore session is active.

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

Component: Untriaged → Session Restore

It does here. Does this also happen in a fresh user profile with zero add-ons and extensions?

Flags: needinfo?(david)

I tried a new user profile and it does restore sessions.

I tried refreshing my previous profile and, for a while, it restored, then it stopped.

I disabled all extensions, and it still does not refresh.
I also tried toggling the setting on and off just in case.

Flags: needinfo?(david)

(In reply to David from comment #3)

I tried a new user profile and it does restore sessions.

I tried refreshing my previous profile and, for a while, it restored, then it stopped.

I disabled all extensions, and it still does not refresh.
I also tried toggling the setting on and off just in case.

The refresh will place your old Firefox profile on your desktop in a folder named “Old Firefox Data”. If your problem persists, you can partially restore lost information by copying files to the newly created profile. Here you can find more info on how to do this.

https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings#firefox:win10:fx92

Please let us know if this solves your issue.

Flags: needinfo?(david)

No, as I pointed out, refreshing the profile only worked temporarily. I tried refreshing again, and it doesn't restore sessions. It doesn't even restore sessions on a newly created profile consistently.

Flags: needinfo?(david)

(In reply to David from comment #5)

No, as I pointed out, refreshing the profile only worked temporarily. I tried refreshing again, and it doesn't restore sessions. It doesn't even restore sessions on a newly created profile consistently.

Sorry, I mistakenly posted the wrong link to my last comment:
https://support.mozilla.org/en-US/kb/recovering-important-data-from-an-old-profile#w_copying-files-between-profile-folders

The fact that the issue is not reproducible with a new profile indicates the issue you are having is given by some alteration of your profile (some settings that weren't reset after the refresh or even add-ons that were stored in different locations).

I could not reproduce this issue on Firefox 92 nor on the latest Nightly 94.0a1 - tried on Windows 10 x64 and macOS Big Sur 11.5.

Whiteboard: QA-not-reproducible

I'm also experiencing this issue. I've gone as to refresh firefox, disable all my extensions, and even mess around with the firefox files as per the official guide. I also used firefox integrity checks without success. I am running firefox 92 (64). During this process firefox also seems to forget all previous session history while extensions do not. I have checked to ensure that I am not in private browsing mode.

On further information about this bug:

Deleting certain files from profile seems to correct the problem. The sessionstore-backups directory and sessionCheckpoints.json and another session file ending in jsonlz4

Unfortunately the solution is only temporary. After a few restarts, the problem arises again.

Can you share the value of "Fission Windows" from about:support?

Do sessions restore if you've kept them open for more than a few minutes?

Fission Windows
0/1 Disabled by default

I don't think they restore no matter how long they're kept.

Yeah, I can confirm that they don’t restore regardless of time spent open. I had a couple tabs that had been open for over a week continuously and they didn’t restore.

Pure speculation, but I wonder if it may be related to accessibility, since that's something unusual that is turned on for my Firefox install.

I’ve done some double checking. The issue appears to occur even immediately following a refresh of Firefox leading me to believe that it isn’t something that has to do with particular settings and is rather an issue arising from either an installation error or a setting that refuses to reset even after a refresh.

I have similar symptoms as well, although I can't be sure it's the same root cause. And for me it's not 100% reproducible (sometimes it'll work fine, in most cases it won't).

I'm on Linux (Fedora), using the latest stable version (92.0), 64 bit in French (apologies if my translations don't match the exact EN labels).
The issue appeared only for Firefox 92 for me, I'm quite sure I never had it before the update.

In most cases I'm using Firefox for more than an hour, then close it, switch off the computer and use it only several hours later. I have between 10-15 tabs open, half of which are pinned. Session restore is enabled in the preferences (but not "Warn upon browser close").
I tried refreshing, it (probably) improved the situation a bit, but not for a long time.

I don't know how much it's related, but several times Firefox would not open the interface (it's running in the background, but never opens the window). In those cases I kill it, and when I start it again it lost the session. I also noticed it loses some preferences (for example: I watch Youtube with the "cinema" display, and it will revert back to the "small" display).

Additional information:

  • I can't find the option "Restore previous session" in the History menu ("Window recently closed" and "tabs recently closed" are here, but it doesn't display what was closed previously)
  • about:support displays "0/2 Disabled by default"

I'd like to chime in that I'm experiencing this issue as well. At first I thought it was caused by the Panorama Tab Groups extension but have ruled that (and other extensions) out by disabling them. I've also tried to create a new profile and that seemed to fix it for a bit (a couple of days at most) but it's back. Furthermore it's inconsistent so I have no idea what's causing it.

I am running Firefox 92.0.1 on Arch Linux.

Hi All, if you could take a peek at the session history files before quitting Firefox, that might be useful.

Open your active Firefox profile -- there's a button for that on the Profile Folder row of the Troubleshooting Information page. Use the Troubleshooting Information page to help fix Firefox issues

In your profile folder, double-click into the sessionstore-backups folder.

Normally you should find:

  • recovery.jsonlz4 -- live session open and recently closed tabs -- normally updated as often as every 15 seconds when status has changed
  • recovery.baklz4 -- slightly lagged version of recovery.jsonlz4
  • previous.jsonlz4 -- previous session open and recently closed tabs
  • upgrade.jsonlz4-buildid -- session snapshots made during automatic updates

Question 1: does the timestamp on recovery.jsonlz4 indicate that is is up-to-date?

If you are tempted to back up any of these files before quitting, feel free to do so.

During shutdown, Firefox will create a sessionstore.jsonlz4 file at the main level of the profile folder.

Question 2: does Firefox create the sessionstore.jsonlz4 file?

Firefox also may remove recovery.jsonlz4 and recovery.baklz4 from the sessionstore-backups folder, but if "Restore Previous Session" is ticked on the Settings page, it may not (this seems to vary a bit from older versions).

Question 3: does Firefox remove recovery.jsonlz4 and recovery.baklz4?

Answer 1: yes. It updates when there are changes in the session (new tabs are open, etc).
Answer 2: no. There are 4 files in that directory: previous.jsonlz4, recovery.baklz4, recovery.jsonlz4 and upgrade.jsonlz4-20210922161155
Answer 3: no. When Firefox is closed, those same files exist. When it is opened, it takes a few seconds until the previous.jsonlz4 is updated. Both the recovery files get updated fairly quickly.

(In reply to David from comment #17)

Answer 1: yes. It updates when there are changes in the session (new tabs are open, etc).
Answer 2: no. There are 4 files in that directory: previous.jsonlz4, recovery.baklz4, recovery.jsonlz4 and upgrade.jsonlz4-20210922161155
Answer 3: no. When Firefox is closed, those same files exist. When it is opened, it takes a few seconds until the previous.jsonlz4 is updated. Both the recovery files get updated fairly quickly.

Hi David, is that when everything works normally, or when your tabs do not appear as expected?

Regarding #2, it would be at the main level of the profile folder, above/outside of the sessionstore-backups folder, alongside the sessionCheckpoints.json file.

Hi,

It's when my tabs do not appear as expected, which is 95%+ of the times Firefox restarts. I wouldn't be able to tell you what happens when they appear because it's so seldom I can't predict it to check.

The file you refer to isn't there. There is a sessionCheckpoints.json file but no sessionstore.jsonlz4, at least I can't find it on the top level of the profile folder.

Correction. The file sessionstore.jsonlz4 exists after Firefox is closed. Once Firefox is opened, it disappears.

After closing and opening the browser a dozen times just now my tabs were restored as expected but here's my current findings.

Question 1: does the timestamp on recovery.jsonlz4 indicate that is is up-to-date?

Yes, this file's modified time is current.

Question 2: does Firefox create the sessionstore.jsonlz4 file?

Yes, this file was created and the modified time is current

Question 3: does Firefox remove recovery.jsonlz4 and recovery.baklz4?

No, these files were not removed on quitting or re-launching the browser.

I will update if I'm able to see this happen at a time my session does not restore properly.

Hello,

I used Firefox yesterday 3 times:

  • Around 8 AM
  • Around noon, until 13:30
  • Around 6 PM, until 6:30

I haven't started it today yet.

In sessionsstore-backups, I have:
30 sept. 13:23 previous.jsonlz4
30 sept. 18:27 recovery.baklz4
30 sept. 18:27 recovery.jsonlz4
18 sept. 18:09 upgrade.jsonlz4-20210909111653
30 sept. 12:43 upgrade.jsonlz4-20210927115918

Question 1:
Yes, it is up to date.

Question 2:
Yes, I have the sessionstore.jsonlz4 file with date of 30 sept. 18:27

At that point (01 oct. 08:21), I start Firefox. All tabs are correctly displayed.

Question 3:
The 2 files recovery.baklz4 and recovery.jsonlz4 are here, and have the date of 01 oct. 08:21. They seem to be updated every minute or so (with recovery.jsonlz4 updated first, then recovery.baklz4).
Full list of sessionsstore-backups:
30 sept. 18:27 previous.jsonlz4
1 oct. 08:22 recovery.baklz4
1 oct. 08:22 recovery.jsonlz4
18 sept. 18:09 upgrade.jsonlz4-20210909111653
30 sept. 12:43 upgrade.jsonlz4-20210927115918

The file sessionstore.jsonlz4 is now deleted.

I then tried a couple times to stop and restart Firefox, but it always restored the tabs.
I'll keep checking until the bug appears again.

Regards,

Piratmac

Hello,

Following my previous comment: I stopped using Firefox around 9:42 this morning.

I haven't restarted it yet.

In sessionsstore-backups, I have:
1 oct. 09:21 previous.jsonlz4
1 oct. 09:35 recovery.baklz4
1 oct. 09:42 recovery.jsonlz4
18 sept. 18:09 upgrade.jsonlz4-20210909111653
30 sept. 12:43 upgrade.jsonlz4-20210927115918

Question 1: does the timestamp on recovery.jsonlz4 indicate that is is up-to-date?

Yes, it is up to date (last time I ran Firefox).

Question 2: does Firefox create the sessionstore.jsonlz4 file?

Yes, I have the sessionstore.jsonlz4 file with date of 1 oct. 09:42

At that point (01 oct. 12:02), I start Firefox. All tabs are correctly displayed.

Question 3: does Firefox remove recovery.jsonlz4 and recovery.baklz4?

The 2 files recovery.baklz4 and recovery.jsonlz4 are here.
Right after I start Firefox, recovery.baklz4 was dated from 1 oct. 09:35.
After a minute or so, both have the current date.

Full list of sessionsstore-backups (right when Firefox started):
1 oct. 09:42 previous.jsonlz4
1 oct. 09:35 recovery.baklz4
1 oct. 12:03 recovery.jsonlz4
18 sept. 18:09 upgrade.jsonlz4-20210909111653
30 sept. 12:43 upgrade.jsonlz4-20210927115918

The file sessionstore.jsonlz4 is now deleted.

Regards,
Piratmac

Hello,

Following my previous comment: I stopped using Firefox around 12:57.

I have restarted it, and it hasn't opened the window (sorry, forgot to check before starting it).

In sessionsstore-backups, I have:
1 oct. 12:57 previous.jsonlz4
1 oct. 12:57 recovery.baklz4
1 oct. 17:06 recovery.jsonlz4
18 sept. 18:09 upgrade.jsonlz4-20210909111653
30 sept. 12:43 upgrade.jsonlz4-20210927115918

Question 1: does the timestamp on recovery.jsonlz4 indicate that is is up-to-date?

It has the exact current time (17:06).

Question 2: does Firefox create the sessionstore.jsonlz4 file?

That file is now deleted

Question 3: does Firefox remove recovery.jsonlz4 and recovery.baklz4?

The 2 files recovery.baklz4 and recovery.jsonlz4 are here.

Running "ps faux | grep firefox" yields 3 processes:
PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
2756 3.2 3.1 2959716 251136 ? Sl 17:06 0:07 _ /usr/lib64/firefox/firefox --new-window
2942 0.1 0.9 2612396 79340 ? Sl 17:06 0:00 | _ /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 246312 -jsInit 285716 -parentBuildID 20210927115918 -appdir /usr/lib64/fi
2978 0.1 0.9 2615176 77500 ? Sl 17:06 0:00 | _ /usr/lib64/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 112 -prefMapSize 246312 -jsInit 285716 -parentBuildID 20210927115918 -appdir /usr/lib64/

I then killed all firefox processes.

The files are not changed compared to the above situation.

Restarting Firefox yields the following results:

  • recovery.baklz4 now has 17:06 as modification time (after a minute, it goes to 17:12, the current time)
  • recovery.jsonlz4 now has 17:12 as modification time

Running "ps faux | grep firefox" yields 5 processes:
PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
3330 15.4 4.1 3128980 330936 ? Sl 17:11 0:10 _ /usr/lib64/firefox/firefox --new-window
3465 0.8 1.1 2618528 89724 ? Sl 17:11 0:00 | _ /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 246364 -jsInit 285716 -parentBuildID 20210927115918 -appdir /usr/lib64/firefox/browser 3330 true tab
3511 2.2 1.5 2658804 124924 ? Sl 17:11 0:01 | _ /usr/lib64/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 5069 -prefMapSize 246364 -jsInit 285716 -parentBuildID 20210927115918 -appdir /usr/lib64/firefox/browser 3330 true tab
3521 5.5 2.1 2779604 173188 ? Rl 17:11 0:03 | _ /usr/lib64/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 5069 -prefMapSize 246364 -jsInit 285716 -parentBuildID 20210927115918 -appdir /usr/lib64/firefox/browser 3330 true tab
3600 0.5 0.9 2603056 77540 ? Sl 17:11 0:00 | _ /usr/lib64/firefox/firefox -contentproc -childID 4 -isForBrowser -prefsLen 5793 -prefMapSize 246364 -jsInit 285716 -parentBuildID 20210927115918 -appdir /usr/lib64

Could you please let me know if you have other questions and/or tests you'd like me to conduct?

Regards,
Piratmac

(In reply to David from comment #19)

It's when my tabs do not appear as expected, which is 95%+ of the times Firefox restarts. I wouldn't be able to tell you what happens when they appear because it's so seldom I can't predict it to check.

Hi David, I am interested in the case where it doesn't work. Is the problem related to failure to maintain session history files during your session (prior to quit/exit), failure to create the sessionstore.jsonlz4 file during an orderly shutdown, and it that file is not created, what happened to the recovery files (Firefox needs one or the other to restore at startup).

The sessionCheckpoints.json file contains information about whether Firefox shut down properly, but I think the presence of the files is more important.

(In reply to Chris from comment #21)

I will update if I'm able to see this happen at a time my session does not restore properly.

Sounds good, thanks.

(In reply to Piratmac from comment #24)

Following my previous comment: I stopped using Firefox around 12:57.

I have restarted it, and it hasn't opened the window (sorry, forgot to check before starting it).

In sessionsstore-backups, I have:
1 oct. 12:57 previous.jsonlz4
1 oct. 12:57 recovery.baklz4
1 oct. 17:06 recovery.jsonlz4
18 sept. 18:09 upgrade.jsonlz4-20210909111653
30 sept. 12:43 upgrade.jsonlz4-20210927115918

It sounds as though sessionstore.jsonlz4 was missing, if Firefox did not use it to create a new previous.jsonlz4 at the beginning of the session (around 17:06). Or perhaps the file was present but for some reason, Firefox could not process it correctly. However, this is all input for the developers as I do not personally know the exact sequence of events at startup. Perhaps the Browser Console (Ctrl+Shift+J) might have some messages about failures occurring during startup, but it is difficult to open it quick enough to avoid missing things.

Running "ps faux | grep firefox" yields 3 processes:
PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
2756 3.2 3.1 2959716 251136 ? Sl 17:06 0:07 _ /usr/lib64/firefox/firefox --new-window

Running "ps faux | grep firefox" yields 5 processes:
PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
3330 15.4 4.1 3128980 330936 ? Sl 17:11 0:10 _ /usr/lib64/firefox/firefox --new-window

Does it make any difference if you modify your startup command line to not use the --new-window parameter? For example, you could try --new-tab instead.

Hello,

Last run of Firefox was yesterday around 11:30 PM.

Before starting Firefox:

1 oct. 23:27 sessionstore.jsonlz4

1 oct. 23:26 previous.jsonlz4
1 oct. 23:27 recovery.baklz4
1 oct. 23:27 recovery.jsonlz4
30 sept. 12:43 upgrade.jsonlz4-20210927115918
18 sept. 18:09 upgrade.jsonlz4-20210909111653

I then started with "firefox --jsconsole" so that it starts the Browser console at the start.
Note: the "--new-window" comes with the default Firefox shortcut (.desktop file).

Firefox started normally this time.

In the console, I noticed the below errors, although I'm not sure it's related:

WebExtensions: reset-default-search: starting. api.js:183

WebExtensions: reset-default-search: has already ran once and saw panel, exit. api.js:210

[Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIAppStartup.secondsSinceLastOSRestart]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "JS frame :: resource:///modules/BrowserGlue.jsm :: _collectStartupConditionsTelemetry :: line 1589" data: no] 2 BrowserGlue.jsm:1589:9
_collectStartupConditionsTelemetry resource:///modules/BrowserGlue.jsm:1589
BG__onFirstWindowLoaded resource:///modules/BrowserGlue.jsm:1696
BG_observe resource:///modules/BrowserGlue.jsm:1013
_delayedStartup chrome://browser/content/browser.js:2124
_delayedStartup self-hosted:1181

GEThttps://profile.accounts.firefox.com/v1/profile
[HTTP/1.1 401 Unauthorized 910ms]

Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. update.js:26
schedule moz-extension://c8333c6c-75d2-458a-be79-645998654d30/include/update.js:26

Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. extension.js:113
<anonyme> moz-extension://c8333c6c-75d2-458a-be79-645998654d30/extension.js:113

AbortError: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved ConduitsParent.jsm:297
_raceResponses resource://gre/modules/ConduitsParent.jsm:297

Error: Can't find profile directory. 2 XULStore.jsm:66:15
load resource://gre/modules/XULStore.jsm:66
XULStore resource://gre/modules/XULStore.jsm:24

Regards,

Piratmac

Hello,

I've been using Firefox without the "--new-window", and it is working fine so far.
I probably started / restarted it 4-5 times, and it restores the tabs just fine.

Regards,
Piratmac

i am experiencing the same issue, on two different computers, with Firefox 92, both running GNU/Linux pop-os (Pop!_OS) (uname -a shows: "Linux pop-os 5.13.0-7614-generic #14163164715121.04~930e87c-Ubuntu SMP Fri Sep 17 00:24:58 UTC x86_64 x86_64 x86_64 GNU/Linux"). This only began occurring about a week ago.

When the malfunction is occurring, the four files recovery.jsonlz4, recovery.baklz4, previous.jsonlz4, upgrade.jsonlz4-buildid are present within sessionstore-backups, and are being updated.

Question 1:
yes. When the malfunction is occurring, the the timestamp on recovery.jsonlz4 is up-to-date

Question 2:
yes. When the malfunction is occurring, sessionstore.jsonlz4 is created.

Question 3:
no. When the malfunction is occurring, Firefox does not remove recovery.jsonlz4 and recovery.baklz4

Other notes:

  • problem occurs even if extensions disabled

  • on one of my machines, after i started firefox with "firefox --safe-mode" a few times, opening and closing tabs throughout, the problem was fixed and didn't recur even after restarting Firefox normally (so far -- that was only about an hour ago). However, on the other machine, that didn't help

  • i am quitting Firefox by pressing cntl-Q

  • one unusual thing about me is that a remote Firefox instance (not either of the two I have been talking about) has over 100 tabs open, which are synced to my Firefox account. I haven't started this remote Firefox for almost a week (because i don't want it to lose its tabs)

  • when i quit, i get the following error printed to my terminal:

###!!! [Parent][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost

  • here is my ps faux:

bshanks@pop-os:~/.mozilla/firefox/zxbaa03j.default-release$ ps faux | grep firefox
bshanks 4717 5.9 1.7 4249212 582288 pts/0 Sl 08:27 1:39 | | _ /usr/lib/firefox/firefox
bshanks 4950 1.9 0.5 2691560 176396 pts/0 Sl 08:27 0:32 | | _ /usr/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 256891 -jsInit 285716 -parentBuildID 20210903235534 -appdir /usr/lib/firefox/browser 4717 true tab
bshanks 5079 1.0 0.7 27978328 240240 pts/0 Sl 08:27 0:17 | | _ /usr/lib/firefox/firefox -contentproc -childID 2 -isForBrowser -prefsLen 4945 -prefMapSize 256891 -jsInit 285716 -parentBuildID 20210903235534 -appdir /usr/lib/firefox/browser 4717 true tab
bshanks 5249 0.2 0.4 2476336 140496 pts/0 Sl 08:27 0:03 | | _ /usr/lib/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 5605 -prefMapSize 256891 -jsInit 285716 -parentBuildID 20210903235534 -appdir /usr/lib/firefox/browser 4717 true tab
bshanks 24921 0.2 0.4 2478372 138100 pts/0 Sl 08:31 0:03 | | _ /usr/lib/firefox/firefox -contentproc -childID 7 -isForBrowser -prefsLen 6088 -prefMapSize 256891 -jsInit 285716 -parentBuildID 20210903235534 -appdir /usr/lib/firefox/browser 4717 true tab
bshanks 24957 0.0 0.2 2411376 98000 pts/0 Sl 08:31 0:00 | | _ /usr/lib/firefox/firefox -contentproc -childID 8 -isForBrowser -prefsLen 6088 -prefMapSize 256891 -jsInit 285716 -parentBuildID 20210903235534 -appdir /usr/lib/firefox/browser 4717 true tab
bshanks 38006 2.1 0.5 2693244 190572 pts/0 Sl 08:34 0:26 | | _ /usr/lib/firefox/firefox -contentproc -childID 9 -isForBrowser -prefsLen 6089 -prefMapSize 256891 -jsInit 285716 -parentBuildID 20210903235534 -appdir /usr/lib/firefox/browser 4717 true tab
bshanks 102928 0.0 0.1 193304 38332 pts/0 Sl 08:49 0:00 | | _ /usr/lib/firefox/firefox -contentproc -parentBuildID 20210903235534 -prefsLen 6245 -prefMapSize 256891 -appdir /usr/lib/firefox/browser 4717 true rdd
bshanks 102939 0.0 0.2 2390344 77156 pts/0 Sl 08:49 0:00 | | _ /usr/lib/firefox/firefox -contentproc -childID 12 -isForBrowser -prefsLen 6245 -prefMapSize 256891 -jsInit 285716 -parentBuildID 20210903235534 -appdir /usr/lib/firefox/browser 4717 true tab
bshanks 127095 0.0 0.0 6468 920 pts/4 S+ 08:54 0:00 | _ grep -i firefox

i managed to fix my other device using the following steps:

  1. Invoke Firefox with "firefox" (safe mode not needed)
  2. Using the hamburger menu, select Settings
  3. Select Privacy & Security in the left menu, then scroll down to the History heading on the right
  4. Click 'Clear History...'
  5. Uncheck everything except 'Browsing & Download History' (leave 'Time range to clear' at 'Last Hour')
  6. Click OK
  7. Quick Firefox (note: any current tabs will be lost)
  8. Restart Firefox
  9. Open some tabs, quit Firefox a second time, then start Firefox a third time; the tabs you just opened should be there now

NOTE: You might think it would be sufficient to use 'Hamburger menu -> History -> Clear recent history...'; but that doesn't work! You have to use the 'Clear History...' button from within Settings->Privacy and Security. Do they do something different? Or is it essential that the 'Settings' tab is open at the time that recent history is cleared? Other things that DON'T work are: (1) opening the History tab and manually right clicking on each recent entry and selecting Forget about this site; (2) going to 'Hamburger menu -> History -> Clear recent history...', unchecking everything except 'Browsing & Download History', but then clicking Cancel instead of OK.

NOTE: Before i did the above, i saved a copy of my profile folder. After Firefox is fixed by doing the above steps, i can break it again by (1) quitting firefox and then (2) overwriting the current sessionstore.jsonlz4 with the old sessionstore.jsonlz4 from when it was broken.

NOTE: When Firefox is in the broken state, i quit Firefox and made a copy of sessionstore.jsonlz4 and then inspected it using https://www.jeffersonscher.com/ffu/scrounger.html
sessionstore.jsonlz4 did not contain any open tabs.

NOTE: When Firefox is in the broken state, i inspected sessionstore-backups/recovery.jsonlz4 using https://www.jeffersonscher.com/ffu/scrounger.html
recovery.jsonlz4 contained the correct NUMBER of open tabs, however the URLs of the open tabs were wrong; the first tab was reported as about:home and every other tab was reported as about:newtab

My hypothesis is that there is some sort of corruption somewhere in sessionstore.jsonlz4, and when Firefox starts up it tries to load the corrupted data and this causes it to become corrupted in a way such that when it later tries to record open tabs, the first tab is recorded as about:home and other tabs are recorded as about:newtab, as can be seen in recovery.jsonlz4. When Firefox terminates it removes these seemingly-empty entries from the list written to sessionstore.jsonlz4. Removing recent 'Browsing & Download History' via 'Hamburger menu->Settings->Privacy & Security->Clear History...' somehow resets some corrupted state such that when Firefox next terminates it writes an uncorrupted sessionstore.jsonlz4, although the part of the corrupted state causing the current session's tabs to be forgotten is still present in memory until Firefox quits. Upon quitting and restarting Firefox, now all corruption is gone, and tabs are being remembered again.

It is curious that (a) 'Hamburger menu -> History -> Clear recent history...' doesn't clear the corruption even though 'Hamburger menu->Settings->Privacy & Security->Clear History...' does, and (b) on one of my machines, starting Firefox in Safe Mode was sufficient to clear the corruption, but on the other machine, 'Hamburger menu->Settings->Privacy & Security->Clear History...' was necessary instead. One hypothesis is that various different kinds of sessionstore.jsonlz4 deviations occur from time to time, but prior to Firefox version 92, there was some automatic normalization that fixed it -- and perhaps something changed in Firefox version 92 that made it less tolerant to these deviations.

On my first machine, i didn't save a copy of the corrupt profile folder before i fixed it using --safe-mode. On my second machine, i have a copy of the old corrupt sessionstore.jsonlz4 -- I could attempt to isolate which part of my old sessionstore.jsonlz4 was corrupted by converting to a json, removing some part, converting it back to a jsonlz4, and seeing if it is still corrupted. However, i don't know how to convert back from a .json to to a .jsonlz4 -- perhaps someone could tell me how to do that? https://superuser.com/a/1363748 suggests a way, however, i can't find the 'Scratchpad' that it mentions, and in Web Console i don't know how to "change Environment from Content to Browser" -- and without that i get "ReferenceError: OS is not defined" when i try to do things like OS.File.read.

Tried the suggested workaround, and it doesn't work for me.
That said, pursuing some of those steps produces similar results. Specifically, recovery.jsonlz4 contains about:blank instead of my open URLs.

I’ve cleared that data a few times without success fully being able to restore the tabs afterwards.

Also one thing I’ve noticed is that Firefox seems to be able to recover the data if it is killed directly by Windows during a shutdown, but not upon a restart. There is still the caveat that cookies don’t appear to be stored even in this case.

On the good news front, it appears that Firefox 93 doesn't have this bug. I just updated and it seems to be restoring sessions alright so far, though it may present later.

I’m still having the issue on Firefox 93. Even after redownloading the browser directly from Mozilla. Is it possible that the issue could be related to touchscreen or tablet support? It’s a feature that I know is enabled on my computer since it has a touchscreen and it could explain why only some people have had the issue. Supporting this hypothesis is the fact that Firefox hasn’t worked on this computer ever as it was purchased recently. Having linked and unlinked my Firefox account could also have something to do with it. By this point though I’m really just throwing out ideas.

Alright, 93 fixed the bug for me on one computer. But not on another. Tablet/touchscreen is definitely not the issue in my case. The only unusual parts of my setup are, I store the profile in a non-standard location, and I have accessibility turned on and in use. Can't think of anything else or why it seems to work for everyone else but not me, or even not me on one computer.

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)

I found a way to reliably reproduce the corrupted state on my machine. I am running 93.0 (64-bit).

The corruption is contained in the sessionstore.jsonlz4 file that I uploaded. To reproduce:

  1. Quit Firefox (and make sure Firefox is not still running)
  2. In the active Firefox profile folder, replace the current sessionstore.jsonlz4 with the corrupted sessionstore.jsonlz4
  3. Start Firefox. Firefox will behave normally during this session but the next time you quit, it won't save your tabs.
  4. Navigate to google.com
  5. Quit Firefox
  6. Restart Firefox. Google.com is not open.

Here is how I created the corrupted sessionstore.jsonlz4 file that I uploaded in the previous comment:

  1. Invoke firefox with
    firefox --safe-mode

(safe mode is not actually needed here, i just did it that way to make sure that the
problem still occurs with my extensions disabled)

  1. Close all tabs except one

  2. In the remaining open tab, navigate to:

https://www.apple.com/macbook-pro-14-and-16/

  1. Wait about a second, then type cntl-W to close the tab and,
    since this is the last tab, close the entire browser

NOTE: DO NOT QUIT WITH cntl-Q, that doesn't cause the problem;
the problem only occurs if the tab visiting the URL
given above is closed

In order to create the corruption, I think that the tab containing https://www.apple.com/macbook-pro-14-and-16/ must be closed but I don't think it always needs to be the last tab when it is closed. But I am not sure / didn't explore this.

(In reply to Bayle Shanks from comment #36)

Created attachment 9246517 [details]
Corrupted sessionstore.jsonlz4

In this file, the last closed tab is stored as a closed tab in an open window. In other words, after restore, you'll see the Apple tab under History > Recently Closed Tabs. This seems to be a change from earlier versions (at least on Windows) where I think both a regular exit AND closing the last tab restored that tab automatically.

The sessionstore data structure in your file looks like:

{
  "version":["sessionrestore",1],
  "windows":[
    {
      "tabs":[],
      "selected":-1,
      "_closedTabs":[
        {
          "state":
            {"entries":[
              {
                "url":"https://www.apple.com/macbook-pro-14-and-16/",

So unlike earlier versions that kept the last tab in the tabs array, Firefox 93 moves it to the _closedTabs array.

But that isn't actually the main problem. The killer bug is when that window is restored, new tabs opened in that window are not added to the tabs array and therefore are lost from session history unless you close them (in which case they are added to the _closedTabs array).

You can observe this in near real time by opening several tabs in that window, and then after allowing time for the file to be updated, checking the contents of recovery.jsonlz4 from the sessionstore-backups folder (using the Scrounger tool to decompress and list out the contents by dropping the file on the box and clicking the Scrounge URLs button).

If you select all but one of the tabs in the problem window and move them to a new window, then after the next update (up to 15 seconds), recovery.jsonlz4 will have the correct tabs. The problem seems to be specific to the initial window. If you exit/restart, the new window restores properly while the problem window disappears.

After an arduous mozregression, it appears that the new behavior of not restoring the last tab was intentional (bug 490136). However, something about the patch causes the new problem.

2021-10-18T18:37:53.734000: DEBUG : Found commit message:
Bug 490136 - fix last tab re-opening after the close with session restore. r=Gijs

If one closes the last tab with the session restore enabled, it will re-open after restart.
Fix that by closing completely the tabs before the stop of the browser.

Differential Revision: https://phabricator.services.mozilla.com/D118270
Flags: needinfo?(pyjacpp)

I was able to reproduce this session restore problem after doing the str in comment #37 then comment#0 in Nightly 95.0a1 Windows10.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Regressed by: 490136
Has Regression Range: --- → yes

I second the suspicion that this was caused by the fix to 490136. In https://bugzilla.mozilla.org/show_bug.cgi?id=490136#c38 I describe how I reproduce the problem (but somebody told me my repro did not work for them, so I guess we need a third opinion.)

Thanks for your efforts, everybody!

Severity: -- → S1
tracking-firefox94: --- → ?
tracking-firefox95: --- → ?
Priority: -- → P1
Keywords: dataloss

The issue is that after a session restore we hit this early return: https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/browser/components/sessionstore/SessionStore.jsm#3983-3985 when asking for state for the restored window, and always end up deciding the window hasn't loaded yet and we need to return the previously saved state, instead of collecting up-to-date info for the window. Still trying to figure out why that is and/or what normally marks windows as loaded/restored.

(In reply to :Gijs (he/him) from comment #43)

The issue is that after a session restore we hit this early return: https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/browser/components/sessionstore/SessionStore.jsm#3983-3985 when asking for state for the restored window, and always end up deciding the window hasn't loaded yet and we need to return the previously saved state, instead of collecting up-to-date info for the window. Still trying to figure out why that is and/or what normally marks windows as loaded/restored.

Seems this is because the restoreTabs call here: https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/browser/components/sessionstore/SessionStore.jsm#4211-4214 is and was always conditional on there being any tabs to restore. But that call was also the only thing that marked a window as "restored": https://searchfox.org/mozilla-central/rev/36aa22c7ea92bd3cf7910774004fff7e63341cf5/browser/components/sessionstore/SessionStore.jsm#4405-4410 . The only reason we haven't hit this before is that before bug 490136 it would have been very hard (maybe impossible) to hit that code with 0 tabs to restore for a window - we wouldn't have saved such a window.

Moving the checks that mark a window "restored" to the callsite in restoreWindow, outside of the condition checking that there are tabs (which, btw, is the only callsite for restoreTabs), appears to be sufficient to fix this issue. Going to have to see if this doesn't break reopening closed tabs and if it doesn't break any existing tests, and then write an automated test.

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED

Set release status flags based on info from the regressing bug 490136

status-firefox93: --- → affected
status-firefox94: --- → affected
status-firefox95: --- → affected
status-firefox-esr78: --- → unaffected
status-firefox-esr91: --- → unaffected

Not tracking for 94 given where we are in the cycle and it not being a new issue, but I'll consider a very low-risk fix for our last beta build if it's ready in time.

status-firefox93: affected → wontfix
tracking-firefox94: ? → -

I have nothing to add and Gijs did the patch so I clear my needinfo.

Flags: needinfo?(pyjacpp)

(In reply to Ryan VanderMeulen [:RyanVM] from comment #46)

Not tracking for 94 given where we are in the cycle and it not being a new issue, but I'll consider a very low-risk fix for our last beta build if it's ready in time.

Given that as part of bug 1724959, we're going to advertise a bit more than usual session restore on 94 (bug 1724962), I think we should try to track this for 94, of course with the due process in terms of risks and testing. @romain @ryanvm

Flags: needinfo?(ryanvm)
Flags: needinfo?(rtestard)
Flags: qe-verify+
Whiteboard: QA-not-reproducible

Users who had the close tab modal enabled will see an infobar after updating to 94 that will teach them how to restore a session so we expect that existing users will restore more with 94 as a result. If the risk is acceptable I agree it's particularly valuable to uplift to Beta 94.

Flags: needinfo?(rtestard)

Adrian, can you please help clarify the scenario when this happens? I'm unclear if this reproduces consistently when users restore their previous session through Hamburger Menu>History

Flags: needinfo?(adrian.florinescu)

For the moment, I've just tested on Windows 10 with Nightly 95.0a1 and Release 93, taking in account all the above comments.
With session restore off, there doesn't seem to be any issues regardless of the quit option.

For the session restore on, there are two parts of this bug, the trigger which corrupts the sessionstore.jsonlz4 and then a set of susequent full loses of session restore depending of the chosen quit option.

trigger steps:
  1. Have one window with one tab (any random link) to which apply Ctrl+W (this will quit the browser) - any other quit option will not enable the corruption.
  2. Reopening the browser will restore nothing but the window will be in the corrupted sessionstore.jsonlz4 state.
subsequent session restore loss:

A. For browsing done in the restored window, subsequent session restores will be lost if the quit is done with: Ctrl+Shift+Q or File/Exit
B. For browsing done in the restored window, , subsequent session restores will be properly restored if the quit is done with the x button or OS close menu.

Flags: needinfo?(adrian.florinescu)
Attached patch Patch for beta — — Splinter Review

Approval Request Comment
[Feature/Bug causing the regression]: bug 490136
[User impact if declined]: broken session restore
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: no
[Needs manual test from QE? If yes, steps to reproduce]: yes, see comment #41 / #52
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not exceedingly
[Why is the change risky/not risky?]:
I'm moving 5 lines of JS code from the top of one function to the caller of that function. That caller is the only caller. No reordering is happening, but I'm making sure that that code executes even in the case that there are no tabs, which we know can happen after bug 490136 (the conditions for the failure precede that bug, but it likely wouldn't have been hit because windows without tabs wouldn't have been stored in session restore at all). This is all accompanied by an automated test.

I've also done manual and automated testing on beta, verifying that the patch works, and rebasing the test around bug 1733425 not existing on beta (had to re-add a JSON.parse to the automated test; no changes to the code under test for the uplift).

Attachment #9246959 - Flags: approval-mozilla-beta?
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/18eda44669c3
fix restoring sessions that closed all tabs, r=mconley

https://hg.mozilla.org/mozilla-central/rev/18eda44669c3

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox95: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
tracking-firefox94: - → +
tracking-firefox95: ? → +
Flags: needinfo?(ryanvm)

Comment on attachment 9246959 [details] [diff] [review]
Patch for beta

Sounds like this bug is likely to hit us more in the Fx94 release than was previously anticipated based on the wider promotion of session restore coming in it. Approved for 94.0b9 to avoid a known bad case around that.

Flags: needinfo?(dao+bmo)
Attachment #9246959 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

FWIW, Nightly looks good, thanks.

QA Whiteboard: [qa-triaged]

Acounting for scenarios described in comment #41 / comment#52 with a regression testing area for the session restore, excluding the known bug 1732366 , everything seems good to go. Thank you :gijs and :ryanvm for getting this in 94.

Verified on

Enviroments
Nightly 95.0a1 (2021-10-21) 
Beta 94.0b9

on

Ubuntu 20.04
WIndows 10
Mac 11.5.1
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
status-firefox94: fixed → verified
status-firefox95: fixed → verified
Flags: qe-verify+
OS: Unspecified → All
Hardware: Unspecified → Desktop

I've seen this issue crop up a few times since it was fixed including today with v75. It's definitely much less frequent than it was before the fix but it's still happening on occasion. Should I file a new bug report?

(In reply to Chris from comment #60)

I've seen this issue crop up a few times since it was fixed including today with v75.

I'm guessing you meant 95? If you're on 75 then, well, I don't know what to tell you... ;-)

It's definitely much less frequent than it was before the fix but it's still happening on occasion. Should I file a new bug report?

Yes please. If you have steps to reproduce, even better.

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

Attachment

General

Creator:
Created:
Updated:
Size: