Bug 759252 makes use CSS animations to animate loading throbbers for tabs. I noticed that my Nightly keeps using a constant amount of CPU and reproduced that with lots of tabs (only 3 of them loaded) with really simple pages. After commenting out the animation rules for .tab-throbber in browser/themes/shared/tabs.inc.css Nightly's CPU usage is back to 0-1% from a constant ~12%. The gecko profiler shows that the refresh driver is active a lot even though I have only simple static pages without anything changing.

The platform I'm on might be important.

I think I'm seeing this on Windows too. I noticed high CPU usage without any apparent activity on latest Nightly. Not sure how to validate that it's the same bug with the official distributed nightly though.

Another workaround is: .tab-icon-image:not([src]):not([pinned]), .tab-throbber:not([busy]), .tab-throbber[busy] + .tab-icon-image { + animation: none !important; display: none; } It seems that setting display:none doesn't "stop the animation".

Avi, I think you could create a userChrome.css in your profile folder and copy the rules above into it.

dholbert this looks like another case of CSS animation still running when hidden. (I can't find the other bug). Can we see if 'layers.offmainthreadcomposition.async-animations;true' solves this problem? When OMTA compatible animations are running on B2G the main thread still goes to sleep.

(In reply to Benoit Girard (:BenWa) from comment #5) > Can we see if 'layers.offmainthreadcomposition.async-animations;true' solves > this problem? Same amount of CPU usage with that pref flipped for me.

(In reply to Benoit Girard (:BenWa) from comment #5) > dholbert this looks like another case of CSS animation still running when > hidden. (I can't find the other bug). Based on comment 3 ('It seems that setting display:none doesn't "stop the animation"'), this sounds like an instance of bug 962594.

So, to the extent that this is a platform bug, this is a dupe of bug 962594. We should probably either dupe it bug, or reshape this into a front-end bug about applying the workaround in comment 4. needinfo=tim to decide which of those is better here. (If the workaround isn't too much trouble, it's probably worth taking, to fix this in the near term. The workaround code would probably want to be accompanied by an XXX comment pointing to bug 962594, so that we remember to remove the workaround when bug 962594 is fixed.)

(In reply to Daniel Holbert [:dholbert] from comment #8) > So, to the extent that this is a platform bug, this is a dupe of bug 962594. > We should probably either dupe it bug, or reshape this into a front-end bug > about applying the workaround in comment 4. needinfo=tim to decide which of > those is better here. Really depends on whether bug 962594 will be fixed in the Firefox 32 time frame. To me it doesn't look like it will.

Comment on attachment 8430155 [details] [diff] [review] patch Review of attachment 8430155 [details] [diff] [review]: ----------------------------------------------------------------- Tested that the workaround works - it does and stops the animation. Thanks!

I suspect this might make bug 1015317 disappear too.

(In reply to Dão Gottwald [:dao] from comment #9) > Really depends on whether bug 962594 will be fixed in the Firefox 32 time > frame. To me it doesn't look like it will. (I agree that that's unlikely. It's something we'd like to fix soon, but it's not high enough in the priority-queue that anyone's actively working on it yet.)

https://hg.mozilla.org/integration/fx-team/rev/1979a1b89b46 Marco, please add this to the current iteration.

Added to Iteration 32.3

Hi Dao, any recommendation if this bug should be set to [qa+] or [qa-] for verification.

Unfortunately, I'm not able to reproduce this issue with Nightly 20140527; I get the same results as with latest Nightly (Build ID: 20140602030202): CPU is around 3% after I load 5-6 websites and ~10 New tab pages. Tested on Mac OS X 10.9.2 and Ubuntu 14.04 LTS 32bit. Am I missing something here?

I have no idea why you wouldn't be able to reproduce this. Maybe dholbert knows.

I don't, either. (I never actually directly reproduced this; I was just going off of ttaubert's comments, so I'm not sure how noticable this was in the first place, or how many tabs were required to trigger this.) It's entirely possible that UI code already does something else that keeps us from animating these images (like removing them from the DOM, or clearing the throbber's class attribute), but we don't always do that thing, and Tim hit this in a case where we hadn't done it. Tim (or anyone else who could reproduce this): can you still reproduce this in old nightlies?

Using mozregression on OSX I can confirm the regression using this STR: 1) Wait for mozregression open the browser 2) Press Cmd+T 50 times 3) Open the Activity Monitor and filter for "Nightly" 4) Focus Nightly again and wait a minute to let it stabilize 5) On my system the "bad" Nightlies are at ~11% CPU usage Using the above STR I get the following range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b40296602083&tochange=e9b2b72f4e6c (Which includes bug 759252.) Playing the game the other way around I get the following range for when it got fixed: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e017c15325ae&tochange=1e712b724d17 (Which includes this bug.) Good Nightlies settle at 1-2% after while.

Thanks for your help! Finally, I was able to reproduce this issue with Nightly 2014-05-27 on Mac OS X 10.9.3 - the CPU usage was around 14%. Verified as fixed with latest Nightly (Build ID: 20140603030220) on Mac OS X 10.9.3, Ubuntu 12.04 x32 and Windows 7 x64 - CPU remains around 2%: Mozilla/5.0 (X11; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0