712731 - Adaptive tab activity throttling

Status: RESOLVED INCOMPLETE

(Core :: Performance, enhancement)

Description

[(dormant account)]

This bug is based on a conversation with bz. 
Things we do right now:
1)  setTimeout and setInterval are clamped to run no more than once a second
2)  The refresh driver is clamped to no faster than 1Hz, with a doubling of the clamp on every tick
We may need to clamp invalidation:
"invalidation is not clamped yet, but it's about to be, and in any case I bet it gets optimized away in background tabs"

Would be good to adjust this to
1) Block all event processing on background tabs during user activity
2) Do tab cost accounting and punish resource hog tabs by clamping their activity more aggressively

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

See discussion also in mozilla.dev.platform

Comment 3

[David Teller [:Yoric] - still alive but not very active]

Somewhat related to bug 692420.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm sure that this has been considered, but as there are an increasing number of web applications that are meant to be left in background tabs (non-flash-based media players as a good example) we should ensure that clamping the processing time doesn't interfere with those experiences.

Comment 5

[cheater]

I think my comment ( https://bugzilla.mozilla.org/show_bug.cgi?id=675539#c72 ) on another bug ( https://bugzil.la/675539 - "Automatically unload (stall/hibernate) longly unused tabs to free RAM") applies directly, so I'll just copy paste it without editing.

"""
Guys, really the whole point of this bug is that every 2 months a new clone of BarTab pops up on AMO and none of them work. So why don't you just create an API which defines a method to unload the tab, and leave all this esoteria (i.e. data loss, how to do the GUI, etc) up to the plugin developer? Let's face it, the functionality of unloading tabs can only be done in-house, but you guys will never be able to figure out one perfect way to do it which will not **** off 30% of all Firefox users. So my suggestion is: do it, and leave it as an option to those who know. See what happens, how the plugins are used and how they evolve, and in time consider integrating a working solution into Firefox.
"""

tldr: implement the API, leave it up to addons to use it. Responsibility for figuring out the exact details of the API's use are taken out of your hands and typical plugin usefulness free-market capitalism delivers the best user interface and behaviour for it.

Comment 6

[Asif Youssuff]

This is now parity-chrome - https://blog.chromium.org/2020/11/tab-throttling-and-more-performance.html

Comment 7

[Andrew McCreight [:mccr8]]

This bug is kind of like a vague idea filed more than a decade ago. There's ongoing work on making inactive pages do less, and I don't think this bug is very useful at this point.