Sleeping Tabs: Ability to pause tabs (not push out of RAM) after a certain time.
Categories
(Core :: DOM: Content Processes, enhancement, P5)
Tracking
()
People
(Reporter: mr_luminatus, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: parity-edge)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
Actual results:
Firefox keeps waking up the HDD, and all its threads have activity, even when Firefox is minimized. I use NoScript and uBlock, yet there's still scripts from tabs or whatever running in the background.
Expected results:
I'd like to be able to suspend and resume Firefox when I'm not using it, as I'd still like to access my tabs without reloading it (ie. not having to close it completely).
All I can find are tab suspending addons like:
addons.mozilla.org/en-US/firefox/addon/ff-tab-suspender/
Which used up all my 8GB of RAM, probably trying to suspend all of my 200-something tabs, and putting them out of RAM (I had perhaps 10 tabs active this session).
I have 0 things I want to be continuously running in the background. So for me, it would be perfect if I could have all other active tabs paused besides the one I'm at, unless it's playing media or loading the site. So that should be one option you should be able to select.
Another option is to just pause tabs that you haven't accessed for a certain time.
So Firefox would be pretty much paused if you open a new tab, as all other tabs are paused in the first mode.
| Reporter | ||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 2•6 years ago
|
||
If someone wanted to work on this, there are plenty of interesting places to start:
-
Why is Firefox doing anything in the first place? Is NoScript missing something? Does some code in Gecko have a timer that just wakes up occasionally and checks something? This is a system debugging problem and it's not immediately obvious to me how to approach it. But understanding this could lead to an easy, narrow fix.
-
Are web sites that wake up occasionally a problem for everyone? Is it a privacy or power usage issue? If so, rather than a new Firefox mode, maybe we should consider restricting what content can do when the computer's in certain modes. Or all the time.
-
Can we just use some OS-level hack to suspend a whole process tree? No, you'd want to quiesce first, give Firefox components a chance to make sure data is flushed to disk and such.
-
This mode would obviously break some web sites. What will the user experience be? They just miss reminders from their Google Calendar sometimes? What can we do to match user expectations as much as possible? Is "unless it's playing media or loading the site" the right criterion? Etc.
None of that looks like JS engine stuff. Bouncing to Core::General. I'm sad to say this is unlikely to find an interested party within Mozilla to work on it. I could be wrong. But it's a lot of hard work that most users wouldn't notice or care about...
Updated•6 years ago
|
| Reporter | ||
Comment 3•6 years ago
|
||
(In reply to Jason Orendorff [:jorendorff] from comment #2)
Thank you for clarifying the issue. And I agree with your assessments. If you are already subscribed to notifications for a site, having the tab suspended wouldn't matter, I think. But there are definitely cases where you'd want the tab to be active.
I think if more people kept and eye on the task manager in FF, they'd be aware of the issue and find it unnecessary, or even potentially privacy/security compromising ("what is it doing when I'm not using it whatsoever?"). Even more alarming when you're not blocking ads and crapware scripts! Even something as simple as Google search has some background activity. Thankfully you can use it without js, but then you have to allow google.com js for using the Google mail -- very few would bother to toggle it back and forth.
So the simplest solution is to just have a FF mode that suspends all tabs that aren't loading or playing media. To add the extra interface of "do not suspend this tab", or intelligent tab suspension would be quite some extra work for an issue most people aren't aware of.
I will look into the possibility of making an addon for it, even though I have very little experience with it.
Comment 4•6 years ago
|
||
(In reply to mr_luminatus from comment #3)
(In reply to Jason Orendorff [:jorendorff] from comment #2)
Thank you for clarifying the issue. And I agree with your assessments. If you are already subscribed to notifications for a site, having the tab suspended wouldn't matter, I think. But there are definitely cases where you'd want the tab to be active.
I would think in cases where the user chooses to get notifications, such as a calendar, then that tab would not be paused. There should be a mechanism to keep certain tabs active by choice/decision.
| Reporter | ||
Comment 5•6 years ago
|
||
(In reply to Worcester12345 from comment #4)
I would think in cases where the user chooses to get notifications, such as a calendar, then that tab would not be paused. There should be a mechanism to keep certain tabs active by choice/decision.
Yes, if the notification comes only by the tab being active, then the tabs from sites you have subscribed to notifications for should not pause.
But I don't know how it works, I use email to get notifications on my phone.
But I've checked the extension API and it seems there's no way to suspend a tab, easily. But an idea for how to officially implement it:
With a new site permission: "allow/disallow background processes".
And I tried the ff-tab-suspender that I listed in the OP again, and it's better now, but it suspends by unloading them, pushing them into the tab cache (not having to reload it from the URL). That could be useful to save memory, but this time it crashed, not by consuming too much memory, but by resuming a tab.
So not so promising that an extension could be able to pause tabs, unless you inject some kind of js to stop all other scripts in the tab.
Comment 6•4 years ago
|
||
This is parity-edge - https://techcommunity.microsoft.com/t5/articles/sleeping-tabs-faq/m-p/1705434
Updated•4 years ago
|
Updated•3 years ago
|
Andrew, you marked this as a P5 issue before Edge implemented it. Edge users do notice a much worse performance when they give Firefox a try, since Edge now keeps freezing backgrounds tabs in a non-destructive way. This is also a popular request on Mozilla Connect .
Could you please remove the priority level from this issue and let other developers look into the way Edge does it? The developer who posted a lengthy comment here (Jason) hasn't been active on Bugzilla for two years, and Edge's implementation didn't exist back then.
Comment 8•3 years ago
|
||
Jens or Patricia are in better positions to re-evaluate the priority here.
Comment 9•3 years ago
|
||
IIUC we already have:
- Tab unloading under memory pressure conditions, added way after comment 2.
- Situation aware process priorities that should help in reducing CPU load from background tabs.
- In particular, since 108 Firefox also supports efficient mode priorities in Windows for background tabs, too.
Given those, I am not sure what the expected benefit (for Firefox) would be then for this feature. CPU load should already be pretty much reduced, and while reducing the memory load in general is always a good thing, a more aggressive freezing might have consequences for some websites' usability, too, so using all the available memory seems not too bad. I would want to see a clearer case for this before. Patricia, are you aware of any related measurements we could look at?
| Reporter | ||
Comment 10•3 years ago
|
||
(In reply to Jens Stutte [:jstutte] from comment #9)
Tab unloading is great, but there's no need to unload tabs when you have enough memory. And it doesn't restore the tabs seamlessly, seems like it just reloads the URL when using TotalTabSuspender (so is there an addon doing it better?). I've just recently seen a two streamers complain about Chrome slowing down their whole computer by their background processes, but people solve it for themselves simply: by closing Chrome. The solution should be built in: if you're not using the tab, why should it run background processes that potentially slows down the whole system?
And if Firefox had more users, I'd probably have heard complaints from FF users as well.
And as I said 4 years ago: if people kept an eye on their tab process manager, they'd be wondering why as well. I've some Youtube tabs open in the background, not rendering now, and they go from low to medium activity at all times.
I know for sure that a simple solution would work in my use-case: Freeze the tab thread of any non-active (not shown) tab that's not playing media. I have nothing I need to run in the background other than media sometimes.
But of course it would be more complicated than that to make it work seamlessly for everyone, so I'd recommend a freeze tab functionality for addon developers. Then it can be solved by the wider development community.
Comment 11•3 years ago
|
||
We should throttle background tabs more. We do already throttle background tabs quite heavily but there is more we can do.
Stopping background tabs altogether might break stuff. Like, what if you have an email site in the background tab and it should check every now and then whether there are new emails and notify user about those.
We could consider firing timers and rAF even less often in the background tabs and also throttle workers.
Comment 12•3 years ago
|
||
Stopping background tabs altogether might break stuff.
Edge prevents this by using a list of conditions. See the "What activities prevent a site from going to sleep?" section of their FAQ. Users can also add exceptions to a "Never put these sites to sleep" list.
Comment 14•2 years ago
|
||
Just a couple of thoughts, since I am working on https://phabricator.services.mozilla.com/D181772
Maybe we could have a "pause" button or icon somewhere inside a tab, and call something like that, to stop the tab:
xpc::Scriptability::Get(global).Block();
Comment 15•1 year ago
|
||
(In reply to Jason Orendorff [:jorendorff] from comment #2)
If someone wanted to work on this, there are plenty of interesting places to start:
Why is Firefox doing anything in the first place? Is NoScript missing something? Does some code in Gecko have a timer that just wakes up occasionally and checks something? This is a system debugging problem and it's not immediately obvious to me how to approach it. But understanding this could lead to an easy, narrow fix.
Are web sites that wake up occasionally a problem for everyone? Is it a privacy or power usage issue? If so, rather than a new Firefox mode, maybe we should consider restricting what content can do when the computer's in certain modes. Or all the time.
Can we just use some OS-level hack to suspend a whole process tree? No, you'd want to quiesce first, give Firefox components a chance to make sure data is flushed to disk and such.
This mode would obviously break some web sites. What will the user experience be? They just miss reminders from their Google Calendar sometimes? What can we do to match user expectations as much as possible? Is "unless it's playing media or loading the site" the right criterion? Etc.
None of that looks like JS engine stuff. Bouncing to Core::General. I'm sad to say this is unlikely to find an interested party within Mozilla to work on it. I could be wrong. But it's a lot of hard work that most users wouldn't notice or care about...
I think the final and ultimate goal will be like Chromium browsers, dump all tab content to disk (only SSD):
https://old.reddit.com/r/firefox/comments/zskogq/would_it_be_possible_to_save_unused_tabs_to_disk/
https://old.reddit.com/r/firefox/comments/s21f6f/sleeping_tabs_vs_memory_unloading_in_firefox/
This is the trick that Chromium browsers are using to reduce memory to a significant number, this destroys users SSD but whatever, better for battery.
Comment 16•6 months ago
|
||
(In reply to footmenkingdom from comment #15)
This is the trick that Chromium browsers are using to reduce memory to a significant number, this destroys users SSD but whatever, better for battery.
Sounds good. Has anyone attempted this yet with Firefox?
Description
•