Christiane Ruetten [INACTIVE] Assignee
	Description • 8 years ago

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.

	Christiane Ruetten [INACTIVE] Assignee
	Comment 1 • 8 years ago

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.

	Christiane Ruetten [INACTIVE] Assignee
	Comment 2 • 8 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=fef70f5f5cd9

	Mike de Boer [:mikedeboer]
	Comment 3 • 8 years ago

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?

	Christiane Ruetten [INACTIVE] Assignee
	Comment 4 • 8 years ago

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.

	Mike de Boer [:mikedeboer]
	Comment 5 • 8 years ago

(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!

	Christiane Ruetten [INACTIVE] Assignee
	Comment 7 • 6 years ago

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.