-
Notifications
You must be signed in to change notification settings - Fork 28
Existing intervention to add--Background tabs can be suspended #7
Comments
By suspend here do you mean that the tab is killed? We use the word suspect for the behavior in #5. |
Yes.. although kill may be too strong a word as there is state that could potentially be saved and re-used if the browser chooses to keep the tab's title visible in the tab chooser UI. |
What would we have to save in order to return the tab to a resumed state when the user goes back to it? How close can we get to an experience where users don't even notice a tab getting suspended? |
One thing we're considering doing is to suspend tabs more fully than in #5. Specifically the idea is to not run any tasks at all and purging any transient memory instead of killing the process. You don't save as much memory, but it's also non-destructive as far as the user is concerned. For now this is an idea we're designing. Will try to report back once we have some implementation experience. |
That sounds pretty good. Do you have anything you can share about what the heuristic is for when you put a background tab in this state? |
We don't do this at the moment. We're working on it. It won't be clear till we build it what the heuristics will be. My long-term hope is that we do this to all background tabs after a few minutes. But that's an effort that will require years of working with web authors to change their sites to use ServiceWorkers and BackgroundSync. So, at the moment, everything I said above is speculative. |
(As noted in #72, we intend to archive this repository and are thus triaging and resolving all open issues) I filed whatwg/html#7942 for tracking this in HTML. |
Both Chrome and Microsoft Edge can suspend nonvisible tabs. Edge suspends tabs under memory and under some other heuristics I'd have to research to share... but I've not researched the specific heuristics that Chrome uses.
The text was updated successfully, but these errors were encountered: