Last Comment Bug 633421 - Clamp setTimeout/setInterval to something higher than 10ms in inactive tabs
: Clamp setTimeout/setInterval to something higher than 10ms in inactive tabs
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: P1 normal with 2 votes (vote)
: mozilla5
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
:
Mentors:
: 532904 (view as bug list)
Depends on: 665000 836674 646972 647001 652472 663020 669016 876032
Blocks: 379535 588975
  Show dependency treegraph
 
Reported: 2011-02-10 19:30 PST by Boris Zbarsky [:bz] (still a bit busy)
Modified: 2014-12-27 19:57 PST (History)
27 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Pretty easy to do if we want to! (9.13 KB, patch)
2011-02-10 21:19 PST, Boris Zbarsky [:bz] (still a bit busy)
jst: review+
Details | Diff | Splinter Review
Testcase that can be used to test this (215 bytes, text/html)
2011-03-28 12:48 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details

Description Boris Zbarsky [:bz] (still a bit busy) 2011-02-10 19:30:07 PST
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.
Comment 1 Boris Zbarsky [:bz] (still a bit busy) 2011-02-10 19:46:00 PST
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.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-02-10 19:55:27 PST
nsGlobalWindow has its own concept of "active" which seems to do with focus.  I don't think we want to use that here, fwiw.
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2011-02-10 21:19:35 PST
Created attachment 511636 [details] [diff] [review]
Pretty easy to do if we want to!
Comment 4 Andreas Gal :gal 2011-02-10 21:49:18 PST
Chrome is going to set the minimum interval to 0.5Hz I believe.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2011-02-10 22:02:16 PST
Yeah, that's what the attached patch uses as the default pref value.
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-02-11 08:21:06 PST
Or rather it does 0.5s, which is what I think you meant.  We should clearly make it 1Hz to avoid that problem....
Comment 7 Nickolay_Ponomarev 2011-02-23 04:29:55 PST
Chromium issue is http://code.google.com/p/chromium/issues/detail?id=66078 and they seem to use 1s.

dev-doc-needed: https://developer.mozilla.org/en/DOM/window.setTimeout#Minimum_delay_and_timeout_nesting will need to mention this change if it lands.
Comment 8 Johnny Stenback (:jst, jst@mozilla.com) 2011-03-25 17:12:42 PDT
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?).
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-03-25 17:56:02 PDT
*** Bug 532904 has been marked as a duplicate of this bug. ***
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2011-03-25 19:57:53 PDT
Pushed http://hg.mozilla.org/mozilla-central/rev/e328ab1bcb03 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.
Comment 11 Doug Turner (:dougt) 2011-03-26 08:44:24 PDT
is there anything here that mobile/e10s needs to do to get this benefit?
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-03-26 12:48:26 PDT
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).
Comment 13 Doug Turner (:dougt) 2011-03-26 15:43:52 PDT
yes, i think we do.  alon would know specifically.  happy to run a test case.
Comment 14 Alon Zakai (:azakai) 2011-03-28 12:31:05 PDT
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.
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2011-03-28 12:48:08 PDT
Created attachment 522433 [details]
Testcase that can be used to test this
Comment 16 emmbugzilla 2011-04-06 08:39:29 PDT
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.
Comment 17 Boris Zbarsky [:bz] (still a bit busy) 2011-04-06 09:19:59 PDT
> 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.
Comment 18 Boris Zbarsky [:bz] (still a bit busy) 2011-04-06 11:14:33 PDT
I filed bug 648045 and bug 648046 on applying the throttling in more cases.
Comment 19 Eric Shepherd [:sheppy] 2011-04-12 22:02:48 PDT
Documentation updated:

https://developer.mozilla.org/en/DOM/window.setTimeout#Inactive_tabs

Also updated Firefox 5 for developers.
Comment 20 Grant Galitz 2011-12-24 10:23:09 PST
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.
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2011-12-24 10:29:49 PST
> Is there a specific DOM event that gets fired

At this point, yes: http://www.w3.org/TR/2011/WD-page-visibility-20110602/#sec-visibilitychange-event
Comment 22 Grant Galitz 2011-12-24 10:32:32 PST
Thanks

Note You need to log in before you can comment on or make changes to this bug.