Closed Bug 1270732 Opened 8 years ago Closed 5 years ago

Suspend content in tabs which are inactive to save resources.

Categories

(Core :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 675539

People

(Reporter: mrrrgn, Assigned: mrrrgn)

References

(Blocks 1 open bug)

Details

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."
Depends on: 1269917
Blocks: 1269917
No longer depends on: 1269917
Assignee: nobody → winter2718
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.

Duping to bug 675539 which did unloading of tabs. Feel free to un-dupe if I'm wrong.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.