Apr 27 2011,
It's likely this change in behavior was caused by the increase in the minimum interval for timers on background threads. We'll need to do an experiment disabling this behavior to see whether it affects these test cases.
Jun 1 2011,
I apologize for the delay in following up on this bug. This behavior is expected. The jQuery documentation specifically highlights this issue. Search for "Because of the nature of requestAnimationFrame()..." in http://api.jquery.com/animate/ . The jQuery version of this counter is simply coded incorrectly. The slowing down of timers on background tabs is the root cause of the behavior seen on http://cnanney.com/journal/demo/apple-counter-revisited/ , but a similar technique should be used there to avoid queuing multiple animations. Instead of a new one being queued every second, the next one should be queued at the end of the current one. I'm closing this as WontFix -- working as intended.
Jun 1 2011,
Thanks for the information about requestAnimationFrame(). So if I understand... if the countdown demo uses jQuery's animate function properly, queued up animations won't fire all at once when the tab regains focus, instead they never happen at all? So if someone leaves when the counter is at 15, and stays away for 10 seconds, when they come back it will simply continue where it left off at 15? If so, then it would then have to detect when the tab has regained focus, and sync up the digits to where it should be off the current system time. So any clock-type widget that uses jQuery animate will not work properly unless you are constantly syncing it with system time, because if the tab becomes inactive it will simply stop? The second part, http://cnanney.com/journal/demo/apple-counter-revisited/, doesn't use jQuery or animations at all, simply rapidly changing element.style.backgroundPosition, so I don't see how a similar technique would apply. What is the new minimum interval for timers on background threads?
Jun 1 2011,
> So if I understand... if the countdown demo uses jQuery's animate function properly, > queued up animations won't fire all at once when the tab regains focus, instead they never happen at all? Please read the jQuery documentation. It looks like those animations are paused while the tab is in the background. > The second part, http://cnanney.com/journal/demo/apple-counter-revisited/, doesn't use jQuery or > animations at all, simply rapidly changing element.style.backgroundPosition, so I don't see how a similar > technique would apply. What is the new minimum interval for timers on background threads? I didn't look at your main animation loop in depth but basically you should be prepared for the situation where your animation callbacks are called at a much lower rate. For example, you shouldn't have a timer going off once per second which itself sets off another, faster, timer for the animation. The current minimum interval for timers on background threads is once per second. See http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webkit_constants.h?view=markup .
Jun 1 2011,
Ok, thanks for investigating.
Oct 13 2012, Project Member
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
Mar 11 2013, Project Member
Apr 6 2013, Project Member
Sign in to add a comment