always ask when restoring session
Categories
(Firefox :: Session Restore, defect)
Tracking
()
People
(Reporter: Sarkie, Unassigned)
Details
Attachments
(1 file)
|
8.53 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0
Steps to reproduce:
Killed the parent firefox.exe and restarted laptop
Actual results:
All the tabs were restored
Expected results:
It should ask if I wanted to restore all the session, instead of just assuming I want to restore them all
Comment 1•1 year 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•1 year ago
|
||
In the case of an incomplete shutdown of Firefox such as a crash or killing the parent process, we always attempt to restore the session at next start up. The logic is written up in SessionStartup.sys.mjs. This seems like the correct behavior for most users in this situation and I don't think we want to support another exception to this rule. If you really don't want to restore the session after killing the process this way, you can always remove the sessionstore.jsonlz4 and the contents of the sessionstore-backups directory in your profile.
Comment 3•1 year ago
|
||
You can also select the "never remember history" option in Settings > Privacy to avoid saving your browsing session in the first place.
@sfoster
"This seems like the correct behavior for most users in this situation"
Based on what exactly?
Checking how Chrome does it, and it does exactly what is requested here, so maybe most users want to do this.
The issue with the current implementation, I have a crappy website that is causing issues for me, I kill the Pid, then it loads all the sites and loads the crappy website again, causing me issues.
Then your response is not a user friendly response to go and delete some files, whereas Chrome's is user friendly.
Comment 6•1 year ago
|
||
(In reply to Sarkie from comment #4)
The issue with the current implementation, I have a crappy website that is causing issues for me, I kill the Pid, then it loads all the sites and loads the crappy website again, causing me issues.
Ah I see, thanks for clarifying. It sounds like you are killing the whole application to fix a single non-responsive tab. Is that tab preventing you from interacting with the rest of the browser? You should be able to right-click the offending tab and close it. Or, go to about:processes and kill it from there.
I agree that we should not be restoring a non-responsive tab to start the cycle over again. Has it actually popped up a slow script dialog before you quit? If so we should be able to mark that tab for either not restoring at all, or some other opt-in to restore UI for that tab.
Checking how Chrome does it, and it does exactly what is requested here, so maybe most users want to do this.
We do implement the same kind of thing you showed, but we only show the option to restore after 2 successive crashes.
Updated•1 year ago
|
Comment 7•1 year ago
|
||
The severity field is not set for this bug.
:sclements, could you have a look please?
For more information, please visit BugBot documentation.
Comment 8•1 year ago
|
||
(In reply to Sam Foster [:sfoster] (he/him) from comment #6)
(In reply to Sarkie from comment #4)
The issue with the current implementation, I have a crappy website that is causing issues for me, I kill the Pid, then it loads all the sites and loads the crappy website again, causing me issues.
We do implement the same kind of thing you showed, but we only show the option to restore after 2 successive crashes.
The default in the profile for browser.sessionstore.max_resumed_crashes is currently defaulting to 1, but there was a proposal to change it to 2. See bug 1625831.
I don't see how the browser is to know whether a tab is a non-response tab, since that's the purpose of the the "Firefox didnt' shut down gracefully" screen AFAIK - so that a user can selectively restore which tabs they want so as to exclude a troublesome tab. But it seems like the way the browser is being shut down is by-passing that?
Comment 9•1 year ago
|
||
The severity field is not set for this bug.
:sfoster, could you have a look please?
For more information, please visit BugBot documentation.
Comment 10•1 year ago
|
||
I think the only actionable next steps for this issue would be covered by bug 1625831. IOW this is a messaging issue and about providing options for the user rather than a defect as such.
Description
•