User Agent: Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release) Build ID: 20130511120803 Steps to reproduce: (1) Load the attached test case in tab 1 (2) Click the Start button (3) A popup opens in which a counter is displayed. The counter counts up. (4) Move the popup to a location where it will not be obscured by the main browser window (5) In the main browser window, select a different tab, i.e. a tab other than tab 1. Actual results: The counting up slows down radically. Expected results: The counting should continue at the same speed.

Possible duplicate of bug 665000 though I thought the behaviour changed more recently than that.

Hmmm I think this must be by design, the behaviour seems to be controlled by dom.min_background_timeout_value. Set that to a low value and the animation works OK even in a background tab. This is a bit annoying - impacts some code I have that uses Neil Mix's threading library which is based on setTimeout (http://www.neilmix.com/2007/02/07/threading-in-javascript-17/). Start some javascript running and go off to another tab and the javascript slows to a crawl.

This is very much purposeful: we throttle timeouts in background tabs to a 1000ms minimum (compared to 4ms minimum for foreground tabs), to keep them from chewing up CPU. And yes, bug 665000 is about pretty much the same issue. Note that other UAs have the same behavior at this point, for similar reasons.