Closed Bug 1301041 Opened 3 years ago Closed Last year
Add preference to trigger session restore regardless of crash state
I'm guilty of having 50+ tabs open on a typical day. Regular restarts are necessary to keep rotting tabs from hogging resources. Cleaning out unwanted tabs is by far the easiest in `about:sessionrestore`, but it stays empty unless `sessionCheckpoints.json` indicates a crashed session. The proposal is to aid the tab cleanup process by adding a pref like `browser.sessionstore.always_restore` that always triggers a crash recovery on every restart.
I have a trivial PoC working and am loving it. Do you think this would have any chance of landing ever? Would happily submit the patch.
Hi Christiane! I apologize for my tardiness. I would absolutely accept a patch like that and would actually like to add a few acceptance criteria, if you don't mind: 1. Add a pref for it; I think 'browser.sessionstore.always_resume_session' or 'browser.sessionstore.resume_on_startup' would be likely candidates. Default would be `false`. 2. Add a checkbox to toggle this pref in about:preferences, at the bottom of the General > Startup section. We'll need a UX review for that patch, but that's not a big deal I think. 3. At test! But we can work on that together, perhaps even with help from Mike Conley, who wrote a startup test before for sessionstore. What do you think?
Flags: needinfo?(mdeboer) → needinfo?(cr)
Glad that you found some time to look into this. The positive feedback is encouraging. 1. I'll rename the pref to match your first suggestion. Consider it done. 2. I was specifically trying to work around the UX review processes (which I am familiar with) for this trivial feature. I am particularly worried that UX will request changes to the session restore page to not confuse users with a bogus browser crash warning every time the browser starts. In that case we're probably looking at several days of additional work. It can be done, certainly, but I'd propose to postpone this potential overhead until we're getting some feedback how people like the feature. 3. If sufficient, a superficial test "if flag set then restore is triggered" shouldn't be hard, but your and Mike's support is much appreciated there to get me started.
(In reply to Christiane Ruetten [:cr] from comment #4) > 2. I was specifically trying to work around the UX review processes (which I > am familiar with) for this trivial feature. I am particularly worried that > UX will request changes to the session restore page to not confuse users > with a bogus browser crash warning every time the browser starts. In that > case we're probably looking at several days of additional work. It can be > done, certainly, but I'd propose to postpone this potential overhead until > we're getting some feedback how people like the feature. I wouldn't worry too much about a ui-review blocking this feature too much, especially when it's turned off by default. At least, that's been my experience at fx-team!
My patch never landed due to some rather strong requirements around testing which I could not fulfill within an adequate timeframe. I won't be working on this.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.