New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 80639 link

Starred by 8 users

Issue metadata

Status: WontFix
Owner:
Closed: Jun 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

[regression] Looping jQuery animations queue up when tab loses focus

Reported by cnan...@gmail.com, Apr 27 2011

Issue description

Chrome Version       : 11.0.696.57 and 13.0.748.0 canary
OS Version: 5.1 (Windows XP)
URLs (if applicable) :
http://cnanney.com/journal/demo/apple-counter/countdown.php
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: OK
Firefox 3.6.x: OK
  Firefox 4.x: OK
     IE 7/8/9: OK
     Opera 11: OK

What steps will reproduce the problem?
1. Visit http://cnanney.com/journal/demo/apple-counter/countdown.php
2. Open a new tab, making the countdown lose focus
3. After a few seconds, switch back to the countdown

What is the expected result?
Countdown should read the correct time, e.g. if you left the page for 5 seconds, the counter will be 5 seconds down from when you left.

What happens instead?
The countdown is frozen while hidden, and when it has focus again it will rapidly try to catch up to where it should be.


Please provide any additional information below. Attach a screenshot if
possible.

The counter uses jQuery .delay() and .animation() to manipulate the background image for the digits. It seems jQuery's animation queue is not processing when the tab is hidden.

Example 2: 
http://cnanney.com/journal/demo/apple-counter-revisited/ 

This revised counter is pure JavaScript, but uses a similar effect of rapidly changing the digit's background position. You can see a similar issue here if the tab loses focus, when you switch back there is a quick little hiccup in the digits. Again, no other browsers demonstrate this issue.

Originally posted in Chromium HTML5 Group: http://goo.gl/guUIj


UserAgentString: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.57 Safari/534.24,gzip(gfe)
 

Comment 1 by kbr@chromium.org, Apr 27 2011

Cc: jam...@chromium.org darin@chromium.org
Labels: -Area-Undefined -OS-Windows Area-WebKit OS-All WebKit-Core
Owner: kbr@chromium.org
Status: Assigned
Summary: [regression] Looping jQuery animations queue up when tab loses focus
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.

Comment 2 by kbr@chromium.org, Jun 1 2011

Status: WontFix
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.

Comment 3 by cnan...@gmail.com, 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?

Comment 4 by kbr@chromium.org, 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 .

Comment 5 by cnan...@gmail.com, Jun 1 2011

Ok, thanks for investigating.
Project Member

Comment 6 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
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.
Project Member

Comment 7 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-WebKit -WebKit-Core Cr-Content Cr-Content-Core
Project Member

Comment 8 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment