Clamp setTimeout/setInterval to something higher than 10ms in inactive tabs

RESOLVED FIXED in mozilla5



8 years ago
a month ago


(Reporter: bzbarsky, Assigned: bzbarsky)


(Depends on 2 bugs, {dev-doc-complete})

Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)



(2 attachments)

We throttle the refresh driver; we should throttle DOM timers too.  The issue is web compat...

On the other hand, I hear tell that other browsers are considering doing this, so at least we're not alone.
Oh, for refresh driver we throttle to 1Hz, but once 2.0 ships I'll land a patch to throttle to an doubling-each-time interval.

I don't think we want the doubling behavior for DOM timers, though.
nsGlobalWindow has its own concept of "active" which seems to do with focus.  I don't think we want to use that here, fwiw.
Assignee: nobody → bzbarsky
OS: Mac OS X → All
Priority: -- → P1
Hardware: x86 → All
Whiteboard: [need review]

Comment 4

8 years ago
Chrome is going to set the minimum interval to 0.5Hz I believe.
Yeah, that's what the attached patch uses as the default pref value.
Or rather it does 0.5s, which is what I think you meant.  We should clearly make it 1Hz to avoid that problem....
Chromium issue is and they seem to use 1s.

dev-doc-needed: will need to mention this change if it lands.
Keywords: dev-doc-needed
Comment on attachment 511636 [details] [diff] [review]
Pretty easy to do if we want to!

Let's give this a shot! Patch looks good (and I'm fine with either 1 or 2Hz here, maybe go with 1 to match chrome?).
Attachment #511636 - Flags: review?(jst) → review+
Duplicate of this bug: 532904
Whiteboard: [need review] → [need landing]
Pushed except I forgot to fix the commit message... I used a 1000ms clamp, but the commit message still says 500ms.  The correct number is 1000.
Last Resolved: 8 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [need landing]
Target Milestone: --- → mozilla2.2
is there anything here that mobile/e10s needs to do to get this benefit?
I don't think so.  You're already flagging docshells as inactive so images get discarded, right?

I can write up a testcase for you to test whether this patch is working if you want (pretty easy to do a manual test; hard to do an automated one).
yes, i think we do.  alon would know specifically.  happy to run a test case.
I tested to make sure, and this works perfectly on mobile. Great stuff!

On a related note, this might make bug 588975 (stop animating images in background tabs) easier to do, which is also about reducing activity in inactive tabs.
Blocks: 588975
Depends on: 646972
Depends on: 647001

Comment 16

8 years ago
This works on background tabs, but not on active tabs on minimized windows. Is this the expected behavior?

For comparison, in Chrome, the active tab of a minimized window is considered inactive.
> Is this the expected behavior?

For now, yes.  Which tabs are active is under control of the user interface; it might be worth a bug on Firefox to mark the active tab in a minimized window as inactive.
I filed bug 648045 and bug 648046 on applying the throttling in more cases.
Documentation updated:

Also updated Firefox 5 for developers.
Depends on: 652472
Depends on: 665000
Depends on: 667236
No longer depends on: 667236
Depends on: 663020


8 years ago
Depends on: 669016

Comment 20

7 years ago
Is there a specific DOM event that gets fired when the clamping to 1000 milliseconds starts (We would need to register a listener for it first of course though for it to be exposed...)? This currently trashes the JS GameBoy Color emulator audio when it's running inside of an inactive tab, as everything is driven in it at 16 ms intervals by a sole setInterval.

So the question remains, is there a unique DOM event that would fire solely for this throttling, to warn the web app of the slowdown? Doing normal timestamp comparisons is not the best, due to slow browsers (mobile especially) and timestamp checking for automatic pausing could get hacky.
> Is there a specific DOM event that gets fired

At this point, yes:

Comment 22

7 years ago


6 years ago
Depends on: 836674
Depends on: 876032
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.