Session restore after update loads empty windows that do not load
Categories
(Firefox :: Session Restore, defect, P1)
Tracking
()
People
(Reporter: jelle.swaanen, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:144.0) Gecko/20100101 Firefox/144.0
Steps to reproduce:
I have been experiencing this issue for ~2 updates now, these are the steps I performed:
- Use firefox normally, open multiple tabs in multiple windows
- Run
sudo pacman -Suyto perform a system update - Quit firefox using Ctrl+Q to avoid losing tabs when firefox inevitably needs to be restarted
- Reopen firefox
Actual results:
Firefox opens the correct amount of windows according to the session that was open before closing firefox. But all windows contain a only single 'New Tab' tab that does not load correctly. The firefox account button in the toolbar shows that no account is loaded but clicking on the 'Log into firefox account' button does nothing. Going into Settings>Sync shows that the correct account is logged in. I was not asked for my master password, which I normally am when (re)opening a session.
Probably a different issue, but once this happened, I also lost all my browsing history because Settings>Privacy&Security>History>"Clear History When Firefox Closes>"Browsing&Download History" was enabled even though I did not enable it.
Luckily I was able to resolve that by logging out and logging in again.
Expected results:
Firefox should open all tabs that were part of the previous session. And load the firefox account correctly.
|
||
Comment 1•3 months ago
|
||
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.
|
||
Comment 2•2 months ago
|
||
Exactly the same here. I just updated Firefox to the latest version on Manjaro (144.0-1). After restarting the correct number of windows opens, but - as described above - each of them is blank, containing no tabs or bookmarks. Killing the process and restarting does not solve the problem.
|
||
Updated•2 months ago
|
|
|
||
Comment 3•2 months ago
|
||
sthompson to investigate if this is a dupe of 1994969
|
||
Comment 4•2 months ago
|
||
If you're able, could you enable the Browser Toolbox and see if the parent process raised any errors? It sounds like the browser initialization process didn't complete properly, and it would be helpful to pinpoint where that's happening.
In bug 1994969 there's an indication that a failure to load a localized keyboard shortcut on startup is halting the browser, maybe a similar problem to bug 1724360.
|
Reporter | |
Comment 5•2 months ago
|
||
I think that it is likely that that is the same bug as 1994716. I got it once again today without any upgrade taking place. Sorry about the long wait. :
Here is an image with the logs of the event today
|
|
||
Comment 6•2 months ago
|
||
Sigh, yes, this looks the same :( Thank you for confirming with your console information.
While I don't know what the root cause is, I wrote a patch to avoid this case where a window might not start correctly. The patch in bug 1996113 should be released with Firefox 145 on November 11, 2025.
Thanks for the additional information that you had this happen without an upgrade. I've been suspecting that the root cause might be related to upgrades, but it seems like that might not be the case.
|
|
||
Comment 9•2 months ago
|
||
The severity field is not set for this bug.
:sfoster, could you have a look please?
For more information, please visit BugBot documentation.
|
|
||
Updated•2 months ago
|
|
|
||
Comment 10•1 month ago
|
||
We believe that releasing patches for bug 1994642 in 144.0.2 and bug 1996113 in 145 resolved any outstanding issues where an unknown problem with the localization process on startup resulted in Firefox failing to start up completely.
If you see this issue recur in Firefox 145 or later, please feel free to reopen this bug or file a new one.
Description
•