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

VERIFIED FIXED in Firefox 32

Status

()

Firefox
Theme
VERIFIED FIXED
4 years ago
8 months ago

People

(Reporter: ttaubert, Assigned: dao)

Tracking

Trunk
Firefox 32
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(firefox32-)

Details

(Whiteboard: p=1 s=it-32c-31a-30b.3 [qa!])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 1

4 years ago
The platform I'm on might be important.
OS: All → Mac OS X
Hardware: All → x86_64
(Reporter)

Updated

4 years ago
tracking-firefox32: --- → ?

Comment 2

4 years ago
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.
(Reporter)

Comment 3

4 years ago
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".
(Reporter)

Comment 4

4 years ago
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.
Flags: needinfo?(dholbert)
(Reporter)

Comment 6

4 years ago
(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.
Depends on: 962594
Flags: needinfo?(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.)
Summary: Animated loading throbbers causing permanent CPU usage although hidden → Animated loading throbbers causing permanent CPU usage although hidden with "display:none"
Flags: needinfo?(ttaubert)
(Assignee)

Comment 9

4 years ago
(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.
Component: Graphics → Theme
OS: Mac OS X → All
Product: Core → Firefox
Hardware: x86_64 → All
Summary: Animated loading throbbers causing permanent CPU usage although hidden with "display:none" → Implement workaround for bug 962594 to prevent hidden (display:none) loading throbbers from causing permanent CPU usage
(Assignee)

Updated

4 years ago
Flags: needinfo?(ttaubert) → firefox-backlog+
Whiteboard: p=1
(Assignee)

Comment 10

4 years ago
Created attachment 8430155 [details] [diff] [review]
patch
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #8430155 - Flags: review?(ttaubert)
(Reporter)

Comment 11

4 years ago
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!
Attachment #8430155 - Flags: review?(ttaubert) → review+
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.)
(Assignee)

Comment 14

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

Marco, please add this to the current iteration.
Flags: needinfo?(mmucci)
Added to Iteration 32.3
Flags: needinfo?(mmucci)
Whiteboard: p=1 → p=1 s=it-32c-31a-30b.3 [qa?]
(Reporter)

Comment 16

4 years ago
https://hg.mozilla.org/mozilla-central/rev/1979a1b89b46
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 32
Hi Dao, any recommendation if this bug should be set to [qa+] or [qa-] for verification.
Flags: needinfo?(dao)
Depends on: 1017726
tracking-firefox32: ? → -
No longer depends on: 1017726
Blocks: 1017726
(Assignee)

Updated

4 years ago
Blocks: 1015569
(Assignee)

Updated

4 years ago
Blocks: 1014811
(Assignee)

Updated

4 years ago
Blocks: 1014808
(Assignee)

Updated

4 years ago
Flags: needinfo?(dao)
Whiteboard: p=1 s=it-32c-31a-30b.3 [qa?] → p=1 s=it-32c-31a-30b.3 [qa+]
(Assignee)

Updated

4 years ago
No longer blocks: 1017726
Depends on: 1017726
QA Contact: alexandra.lucinet

Comment 18

4 years ago
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?
Flags: needinfo?(dao)
(Assignee)

Comment 19

4 years ago
I have no idea why you wouldn't be able to reproduce this. Maybe dholbert knows.
Flags: needinfo?(dao) → needinfo?(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?
Flags: needinfo?(dholbert) → needinfo?(ttaubert)
(Reporter)

Comment 21

4 years ago
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.
Flags: needinfo?(ttaubert)

Comment 22

4 years ago
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
Status: RESOLVED → VERIFIED
Whiteboard: p=1 s=it-32c-31a-30b.3 [qa+] → p=1 s=it-32c-31a-30b.3 [qa!]
You need to log in before you can comment on or make changes to this bug.