For tabs that are not in focus, not pinned, and not displaying media we should consider suspending content: a.) after they have been out of focus for some period of time and/or b.) use more than a certain threshold of resources. This should provide a big boost to browser performance. Upon refocus suspended tabs should be put into a state which matches the state of a tab just after a "restore previous session."

This idea has come up a lot in MemShrink. I think the big concern is data loss: the user might have some page state that isn't restored properly. Maybe in the modern era where people are used to mobile devices that kill apps off haphazardly it would be okay. Also, Chrome has apparently been working on something like this ("purge and suspend"): https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!topic/project-trim/ig59iJqQbbU It might be worth looking at that for some ideas.

(In reply to Andrew McCreight [:mccr8] from comment #1) > This idea has come up a lot in MemShrink. I think the big concern is data > loss: the user might have some page state that isn't restored properly. > Maybe in the modern era where people are used to mobile devices that kill > apps off haphazardly it would be okay. > > Also, Chrome has apparently been working on something like this ("purge and > suspend"): > https://groups.google.com/a/chromium.org/forum/ > ?utm_medium=email&utm_source=footer#!topic/project-trim/ig59iJqQbbU > It might be worth looking at that for some ideas. Interesting. Losing your place on an infinite scroll site etc... would be infuriating I imagine. Such things should be detectable, if so a simple prioritization algorithm might go a long way: we'll only touch tabs that look stateful as a last resort. Thanks for the link!

We should also avoid tabs with media playing, pinned tabs, maybe some other things as well. But overall, I think this is a really great idea.

This has come up on Android a fair bit too. We use docShell.isActive to control which tab is foreground or background. Background tabs do limit JS setInterval/setTimeout thresholds, and recently added support to pause META REFRESH. Most of the mobile issues are trying to keep background tabs from using network/cpu resources. I have often wondered if we could use the existing BF cache support for freezing/thawing pages. For memory issues, mobile does "zombify" tabs, which saves session and then destroys the <browser> element. Restoration quality is limited to the saved session quality.

(In reply to Mark Finkle (:mfinkle) (use needinfo?) from comment #4) > Most of the mobile issues are trying to keep background tabs from > using network/cpu resources. FWIW I'm planning to start doing more intelligent scheduling of foreground/background stuff later this year, so we can stop running code from background tabs when appropriate.