Brief summary: I have a user profile which reliably does not restore tabs after upgrading to Firefox ESR 128.3.1. A nearly-clean profile created in the same version as the problematic one comes from does restore tabs successfully after upgrade. How can I find out what Firefox is doing that leads it to decide not to restore the tabs from this profile, so that I can then figure out how to get it to not decide to do that? Longer version: I am working to prepare a deployment for my organization to upgrade from its currently-deployed Firefox release (ESR 107.2.0) to a much more recent one (ESR 128.3.1, which I understand to be the current latest ESR). I make much heavier use of and reliance on Firefox than do most in my organization. As part of that, I have hundreds of open tabs in multiple windows, saved by the session-restore feature to be reopened on subsequent launches of the browser. I also have a variety of add-ons installed. (I also have some userChrome-related UI customization, but I have reproduced this issue without that, so I do not think it is relevant.) Because of that heavy use and reliance, part of my process for preparing to deploy a new Firefox release across the organization is to copy my Firefox profile to a test computer, verify that it comes up correctly after the upgrade, and determine whether any manual adjustments (e.g. to new settings, or of the userChrome-related UI customization) is necessary. This also helps position me to assist any other users who may likewise make heavier use of Firefox than most do. This is typically a fairly straightforward process, if a time-consuming and sometimes clunky one. In this case, however, something went wrong. I shut down my primary Firefox instance (on Windows 10), copied the profile directory out, copied it into place on another computer (running Windows 11), launched Firefox 107.2.0 there (to confirm that the profile came up correctly, which it did), shut it down again, upgraded Firefox on that computer to 128.3.1, and launched again. Rather than the profile coming up correctly, the browser opened with none of my hundreds of tabs. There was only one window, and the only tab in that window was displaying my configured default page. The History menu showed the pages I had recently navigated to prior to copying the profile, but the "Restore Previous Session", "Recently Closed Tabs", and "Recently Closed Windows" entries were all grayed out. about:sessionrestore did not show any session content to be restored; its list of windows, tabs, etc., was entirely empty. Other configuration aspects, such as extensions and about:config settings and so forth, were all retained without apparent issues that I have noticed. Investigating led me to reports such as https://support.mozilla.org/en-US/questions/1449541 and https://bugzilla.mozilla.org/show_bug.cgi?id=1901899. The behavior described seems similar to what I am seeing, although the primary-password aspects do not appear in my case; I do not have such a password set, and did not see any prompt which would be related to one. (We have a policy in place to disable setting such a password, and it seemed possible that this might inadvertently trigger the same code path as having the user click to cancel on such a post-upgrade password prompt; however, I have tested the upgrade scenario with all of our Firefox-related enterprise policies removed, and the behavior was identical.) Those reports, among others, suggest that such cases of lost tabs can be recovered from by looking under [profiledir]\sessionstore-backups\, identifying a .jsonlz4 file which contains the session data from the session, and copying that file to recovery.jsonlz4 and/or [profiledir]\sessionstore.jsonlz4. I have experimented with this extensively, and gotten nowhere. The pre-upgrade copy of the profile contains a sessionstore.jsonlz4 file which, when I examine it via the tools from https://github.com/jusw85/mozlz4, appears to contain the correct session state; during launch after upgrade, this file disappears (i.e., gets deleted). The post-upgrade copy of the profile contains sessionstore-backups\previous.jsonlz4 and sessionstore-backups\upgrade.jsonlz4-[datetimestampstring] files which appear to be identical to the previous sessionstore.jsonlz4, and a sessionstore-backups\recovery.jsonlz4 file which is (reported as being) 1KB in size and is presumably empty. If I exit Firefox, delete that "empty" recovery.jsonlz4 file and copy either previous.jsonlz4 or the update.jsonlz4-* file into place under the recovery.jsonlz4 name, then launch Firefox again, the behavior is observed again. The tabs and windows are still not restored; a little while (more than a few seconds, less than a minute) after the Firefox UI becomes available and responsive, the copied-in recovery.jsonlz4 file disappears, and a new one with the "empty" state is created in its place. (I conclude that it's not just having its contents "updated" to the "empty" state, because if I have the file highlighted in Windows Explorer before the Firefox launch, and after launch return to that window and keep pressing F5 to refresh, at first nothing visible changes, but then on a later F5 press Explorer goes from having the correct-size file selected to having no file selected and having an "empty"-state file present.) If I instead - or also - copy the file into place as [profiledir]\sessionstore.jsonlz4, I see the same result. The newly-copied in file disappears after launch, and the tabs are not restored, nor available for restoration. I have reproduced this behavior with various cut-down versions of the profile, including one which narrows it down to only one window and fewer than a hundred tabs, and which strips out the [profiledir]\chrome\ directory which contained the UI customizations. I have created a test "clean" profile with Firefox ESR 102.7.0 (on the same computer where I'm doing the testing work), in which I just open a couple of tabs, set the "restore tabs on startup" preference, and exit. With that profile, the tabs come up after upgrade without issues. That demonstrates that this is not a universal problem, but is somehow being triggered by something about the profile I'm working with. I have just about exhausted all avenues for debugging this with the resources I currently have. I have no idea how to get Firefox to tell me what it is doing in those early launch stages leading up to the point where the .jsonlz4 files get deleted. I'm not even sure it's *possible* to get Firefox to do that without using a debug build or doing custom builds which log status/etc. messages out to file at every step. Without that information, I have no leads on what to try that might bypass the problem. The only idea I have left for getting any further is to try to bisect the profile/session down to a point where the issue *stops* happening, in the hopes of at least creating a minimal reproducing case - and because of the need to downgrade Firefox in order to be able to modify the profile/session, then upgrade it in order to test whether the issue still manifests, each step of the bisect is sufficiently lengthy and manual that I am hesitant to try to go that route without asking for help first. I've considered filing a bug report on Bugzilla, but am not certain that that is the best venue for an appeal like this one, at least not as a first/next step - especially since I don't have a steps-to-reproduce, at least not without attaching a copy of the profile I'm using (which hardly seems like what that is asking for). I've already looked at the open bug reports in the session-restore component there, and not found any which seem to be covering the same behavior I'm seeing. Any suggestions or advice which I might not have already considered and tried?