Open tabs are lost after upgrading Firefox, cannot restore
Categories
(Firefox :: Session Restore, defect)
Tracking
()
People
(Reporter: mozilla.v3c7g, Unassigned, NeedInfo)
Details
Steps to reproduce:
This is reproducible on macOS, several versions (e.g. Tahoe 26.3.1 a). It happens only when you are prompted by Firefox to restart to update (a new window with "restart to update", "restart later", and "no thanks" buttons). It does not happen when you update by going to About Firefox > Update, click to restart to update.
Steps to reproduce:
- Have several tabs opened on an outdated version of Firefox and "Open previous windows and tabs" configured under Settings > General
- Firefox will eventually prompt saying "restart to update", "restart later", "no thanks".
- Click "restart to update"
Actual results:
Opened tabs are lost and it is not possible to restore previously opened tabs (menu option is grayed out)
Expected results:
Tabs are restored, or at least available to restore by command.
Comment 1•19 days ago
|
||
The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•16 days ago
|
||
Thanks for the report! I'll point this over to the Session Restore folks.
Comment 3•16 days ago
|
||
Can you see if you have recent session restore logs in your profile directory (the location is linked in the about:support page). They should be in a sessionstore-logs directory in there.
Comment 4•16 days ago
|
||
This is reproducible on macOS, several versions (e.g. Tahoe 26.3.1 a). It happens only when you are prompted by Firefox to restart to update (a new window with "restart to update", "restart later", and "no thanks" buttons). It does not happen when you update by going to About Firefox > Update, click to restart to update.
Nick, we've had a several similar reports over the years - people losing tabs after an update. In this scenario session restore is unconditional - we attempt to restore automatically, but sometimes at the next startup there is no session to restore and we get a clean session instead. This is the first report I've seen which differentiates between the manner of updating. Do you know how those code paths differ - or can you redirect me to someone that does? I don't have a good way to reproduce this, but its a interesting detail. I wonder if occasionally we're still writing the current session to disk when the update kicks in and kills the process - or something similar?
Comment 5•14 days ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #4)
This is reproducible on macOS, several versions (e.g. Tahoe 26.3.1 a). It happens only when you are prompted by Firefox to restart to update (a new window with "restart to update", "restart later", and "no thanks" buttons). It does not happen when you update by going to About Firefox > Update, click to restart to update.
When you say a "new window" with these buttons, does it look like the dialog in the image in https://firefox-source-docs.mozilla.org/toolkit/mozapps/update/docs/MacElevatedUpdate.html?
Nick, we've had a several similar reports over the years - people losing tabs after an update. In this scenario session restore is unconditional - we attempt to restore automatically, but sometimes at the next startup there is no session to restore and we get a clean session instead. This is the first report I've seen which differentiates between the manner of updating. Do you know how those code paths differ - or can you redirect me to someone that does? I don't have a good way to reproduce this, but its a interesting detail. I wonder if occasionally we're still writing the current session to disk when the update kicks in and kills the process - or something similar?
If it is that dialog, then there are definitely some different code paths that might impact restart because the restart is partially mediated by macOS itself. But I'm not expert in these details -- I'm going to defer to :spohl.
Stephen, do you have any thoughts here?
Comment 6•14 days ago
|
||
If I'm reading things correctly, the restart in the elevated update case (or really, in any case where this extra dialog is displayed) is handled by a "quit-application-requested" notification. I would expect this to be a graceful restart request that should allow for Session Restore to save the current session appropriately. Sam, would you agree?
| Reporter | ||
Comment 7•14 days ago
|
||
(In reply to Nick Alexander :nalexander [he/him] from comment #5)
(In reply to Sam Foster [:sfoster] (he/him) from comment #4)
This is reproducible on macOS, several versions (e.g. Tahoe 26.3.1 a). It happens only when you are prompted by Firefox to restart to update (a new window with "restart to update", "restart later", and "no thanks" buttons). It does not happen when you update by going to About Firefox > Update, click to restart to update.
When you say a "new window" with these buttons, does it look like the dialog in the image in https://firefox-source-docs.mozilla.org/toolkit/mozapps/update/docs/MacElevatedUpdate.html?
Yes, that is the dialog, except it's not the Nightly release.
Thank you for your attention to this report. I tried to reproduce the issue with the following steps:
- mv /Applications/Firefox.app /tmp
- Download and install https://ftp.mozilla.org/pub/firefox/releases/149.0/mac/en-US/Firefox%20149.0.pkg
- Firefox > About Firefox, let it download, click "Restart to update" to update to 149.0.2
I note here that from what I can remember I was prompted to update when I opened the browser, I don't remember having to go to Firefox > About Firefox, downloading and clicking "Restart to update" to get the prompt in question, but up until this point I had not carefully documented anything so I am not sure.
Anyway, after clicking "Restart to update", I get the prompt in question, click Restart again, and... Session is successfully restored, I could not reproduce the issue this way. I don't know if something changed recently that could have addressed it, or if the scenario is not the exact same I did before, or if the issue is intermittent. This is a work laptop with various corporate software that may or may not interfere with things. The last version update that caused the issue was from 147.0.3 to 149.0 from what I can see in the update history. So I tried the same steps above with 147.0.3 -> 149.0.2, but I could not get it to update. After clicking restart I am prompted for privileges to install the update helper, I grant it, I see the Mozilla updater on Activity Monitor doing apparently nothing (no disk, no network, etc), after several minutes nothing happens, if I try to open Firefox the same thing happens again. I tried a couple of times steps 1 through 3 for 147.0.3 and gave up after an hour or so, maybe I did something wrong, I don't know. I'm sorry I did not better document it earlier and that I cannot reproduce, maybe the bug has to be closed...
Can you see if you have recent session restore logs in your profile directory (the location is linked in the about:support page). They should be in a sessionstore-logs directory in there.
I don't, only one file from 2024.
Comment 8•14 days ago
|
||
(In reply to mozilla.v3c7g from comment #7)
Anyway, after clicking "Restart to update", I get the prompt in question, click Restart again, and... Session is successfully restored, I could not reproduce the issue this way. I don't know if something changed recently that could have addressed it, or if the scenario is not the exact same I did before, or if the issue is intermittent. This is a work laptop with various corporate software that may or may not interfere with things. The last version update that caused the issue was from 147.0.3 to 149.0 from what I can see in the update history. So I tried the same steps above with 147.0.3 -> 149.0.2, but I could not get it to update. After clicking restart I am prompted for privileges to install the update helper, I grant it, I see the Mozilla updater on Activity Monitor doing apparently nothing (no disk, no network, etc), after several minutes nothing happens, if I try to open Firefox the same thing happens again. I tried a couple of times steps 1 through 3 for 147.0.3 and gave up after an hour or so, maybe I did something wrong, I don't know. I'm sorry I did not better document it earlier and that I cannot reproduce, maybe the bug has to be closed...
As an FYI for Nick and anyone else who might come across update bugs, I want to note that what is described here, the fact that "nothing seems to happen during an elevated update", is unfortunately and most likely due to bug 2028575. While I had heard of similar issues before, we could not isolate the problem until very recently. I'm going to try and uplift the patch there as far as possible.
However, this does not explain the initial problem described in this bug report about an unsuccessful session restore.
Comment 9•13 days ago
|
||
(In reply to Stephen A Pohl [:spohl] from comment #6)
If I'm reading things correctly, the restart in the elevated update case (or really, in any case where this extra dialog is displayed) is handled by a
"quit-application-requested"notification. I would expect this to be a graceful restart request that should allow for Session Restore to save the current session appropriately. Sam, would you agree?
Yes. this should be the paved path for session restore. We call SessionStore._uninit which should proceed to gather and save the current session to disk via lazy.SessionSaver.run(), and _saveState. Most of that is synchronous, just the write and the actual I/O is async.
Comment 10•1 day ago
|
||
The severity field is not set for this bug.
:nsharpley, could you have a look please?
For more information, please visit BugBot documentation.
Description
•