1016942 - Implement workaround for bug 962594 to prevent hidden (display:none) loading throbbers from causing permanent CPU usage

Status: VERIFIED FIXED

(Firefox :: Theme, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

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.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

The platform I'm on might be important.

Comment 2

[Avi Halachmi (:avih)]

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.

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

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".

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

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

Comment 5

[Benoit Girard (:BenWa)]

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.

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

(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.

Comment 7

[Daniel Holbert [:dholbert]]

(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.

Comment 8

[Daniel Holbert [:dholbert]]

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.)

Comment 9

[Dão Gottwald [:dao]]

(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 10

[Dão Gottwald [:dao]]

Attachment: patch

Comment 11

[Tim Taubert [:ttaubert] (inactive)]

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!

Comment 12

[Mike Conley (:mconley) (:⚙️)]

I suspect this might make bug 1015317 disappear too.

Comment 13

[Daniel Holbert [:dholbert]]

(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.)

Comment 14

[Dão Gottwald [:dao]]

https://hg.mozilla.org/integration/fx-team/rev/1979a1b89b46

Marco, please add this to the current iteration.

Comment 15

[Marco Mucci [:MarcoM]]

Added to Iteration 32.3

Comment 16

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/1979a1b89b46

Comment 17

[Marco Mucci [:MarcoM]]

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

Comment 18

[Ada [:adalucinet]]

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?

Comment 19

[Dão Gottwald [:dao]]

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

Comment 20

[Daniel Holbert [:dholbert]]

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?

Comment 21

[Tim Taubert [:ttaubert] (inactive)]

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.

Comment 22

[Ada [:adalucinet]]

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