1218169 - Hidden CSS animated spinner causes high CPU load on Google search pages if not logged in

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[newsmails]

Attachment: bugFF1.jpg

User Agent: Mozilla/5.0 (X11; Linux i686; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38
Build ID: 20150923215417

Steps to reproduce:

I used :
Firefox 41.0.2 in safe mode (cmd : "firefox --safe-mode")
Seamonkey 2.38 (Build identifier: 20150923215417) in safe mode (cmd : "seamonkey --safe-mode")

I enter the address https://www.google.com
I am redirected on my country page : https://www.google.fr/?gfe_rd=cr&ei=yq0sVtG2EuyX8Qei8bqwAw

On this page the CPU load is ~60 %.



Actual results:

Without doing anything the CPU usage on this page is ~60 %. (see joined image)


Expected results:

The CPU usage may be near 1%.

On the google page if I click on the bottom right link "Utiliser Google.com" I arrive on this page :
https://www.google.com/?gfe_rd=cr&ei=yq0sVtG2EuyX8Qei8bqwAw&gws_rd=cr&fg=1
The CPU usage is near 1%

If you go back on the french page by clicking on "Use Google.fr" the CPU usage goes back to 60%.

Comment 1

[Andre Klapper]

Thanks for taking the time to report this!
Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems. It does not disable plugins which are add-ons.) See http://support.mozilla.com/en-US/kb/Safe+Mode 

And does this also happen with a new and empty profile? See http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile and http://support.mozilla.org/kb/Managing%20profiles

Comment 2

[newsmails]

Quick answer to the first question : I wrote :
"I used :
Firefox 41.0.2 in safe mode (cmd : "firefox --safe-mode")
Seamonkey 2.38 (Build identifier: 20150923215417) in safe mode (cmd : "seamonkey --safe-mode")
"

Comment 3

[newsmails]

I have tested with an empty profile : it does not change anything.
And I remarked the problem with 2 different profiles.

I think that it is something really new ; maybe it arrives with seamonkey 2.38 ?

Comment 4

[alex_mayorga]

¡Hola!

Could you please gather and provide the URL of a profile as described at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

¡Gracias!
Alex

Comment 5

[newsmails]

Must I test with a nightly build as said in the link or with my version ?

Comment 6

[newsmails]

I have tested with my version : Firefox 41.0.2

On an EMPTY page
~40%-45% cpu usage
http://people.mozilla.org/~bgirard/cleopatra/#report=b4bca8c5b284b0ba698cccf13e08bbfec1cad56d

On the google page reported in this bug.
High cpu usage ~70%
http://people.mozilla.org/~bgirard/cleopatra/#report=0dbebcbe6a384c8644b7742a42b974ce6b848fc2

Too bad : your plugin is not compatible with seamonkey...

Comment 7

[ovidiu boca[:Ovidiu]]

Hi,

I have tested on Ubuntu 14.04 with FireFox Nightly 44.0a1 (2015-10-27) and I didn't reproduce the CPU Usage.
Please try with Nightly to reproduce this problem. You can download this version from here:

https://nightly.mozilla.org/

Comment 8

[newsmails]

I can't start nightly on my distrib :
 ./firefox   
XPCOMGlueLoad error for file firefox/libmozgtk.so:
libgtk-3.so.0: cannot open shared object file: No such file or directory
Couldn't load XPCOM.

Future versions will not work with gtk+2 ?

Comment 9

[newsmails]

I tried to install a libgtk-3 package. But it is not better :
./firefox: symbol lookup error: /usr/lib/libgtk-3.so.0: undefined symbol: atk_window_get_type

So is it a bug or future versions will not work with gtk+2 ?

Comment 10

[alex_mayorga]

¡Hola Nicholas!

Do you see anything obviously wrong with these profiles?

¡Gracias!
Alex

(In reply to alertesmails from comment #6)
> I have tested with my version : Firefox 41.0.2
> 
> On an EMPTY page
> ~40%-45% cpu usage
> http://people.mozilla.org/~bgirard/cleopatra/
> #report=b4bca8c5b284b0ba698cccf13e08bbfec1cad56d
> 
> On the google page reported in this bug.
> High cpu usage ~70%
> http://people.mozilla.org/~bgirard/cleopatra/
> #report=0dbebcbe6a384c8644b7742a42b974ce6b848fc2
> 
> Too bad : your plugin is not compatible with seamonkey...

Comment 11

[Andre Klapper]

(In reply to alertesmails from comment #9)
> So is it a bug or future versions will not work with gtk+2 ?

Bug 1207310 (further gtk stuff should probably go to a forum as it's unrelated to this very bug)

Comment 12

[newsmails]

I have started nightly build (sorry for the noise...).
I reproduced on the nightly build

!! To reproduce you need : (is it possible to edit my user story ?)
1- change the preferences :
preferences/privacy/history ==> use custom settings for history
Accept third-party cookies ==> from visited
2- delete the google cookies
3- restart
4- follow my user story

I think that you need to have the same screen as my first attachment.
Look at the next joined image.

It seems that the stress comes from the  google rules to read.

Comment 13

[newsmails]

Attachment: red needed to reproduce

Comment 14

[Nicholas Nethercote [inactive]]

I don't see anything notable in the profiles, but I'm terrible at reading those kinds of profile. Sorry!

Comment 15

[Xavier Delgado]

I've tested it on nightly 45.0a1 (2015-11-01)
Windows 8.1 

Nothing weird.

Comment 16

[Xavier Delgado]

Intel® Pentium(R) CPU G3258 @ 3.20GHz × 2
FF RC 41.0
Ubuntu 14.04

I've got something weird. With this test case, FF CPU grows to 25%. when I leave, it goes to 2%
I have a very powerful CPU. 25% for me is a lot. (like 60% for a less powerful CPU, I guess)

Comment 17

[alex_mayorga]

¡Hola Xavier!

Thanks for your testing.

I'm marking this bug NEW as there are now two separate users confirming this is a problem.

Could you please gather and provide the URL of a profile as described at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem ?

¡Gracias!
Alex

Comment 18

[Xavier Delgado]

Hola Alex.

I've done another test. google.com and google.fr use the same CPU on my PC. 
So I can't say anymore that it's reproduced.

Gracias a ti :)

Javi (o Xavi ;) )

Comment 19

[newsmails]

Xavier,

Did you try to reproduce using my user story in comments 12 and 13 ?

It still have the problem with the new firefox version (42.0).
Google was my home page but it is no more possible.

The CPU usage is normal (~1%) in 2 cases :
- the firefox window is minimized
- the google page is not the active tab

Comment 20

[Xavier Delgado]

Hey,

Actually, you're right.

I'm on firefox 42.0

When 
- I minimize firefox window
- Google page is not the active tab

CPU usage decreases around 1%

Comment 21

[Xavier Delgado]

Have you tried to reproduce bug on others browsers?
(To see if it's a Google issue, or a Firefox issue)

Comment 22

[Xavier Delgado]

Not only Seamonkey. Chrome and IE.

Comment 23

[Xavier Delgado]

Windows 8.1 

On IE,     the change is from 0,6% with Google minimized or on another tab to 6%   when active.
On Chrome, the change is from 0,3% with Google minimized or on another tab to 1,5% when active.

Ubuntu 14.04

(The big change from 2% to 25% is only on Ubuntu 14.04 (Firefox))

Comment 24

[Xavier Delgado]

Windows 8.1 / Firefox 42

Changes from ~6% to ~16%

Comment 25

[newsmails]

> (The big change from 2% to 25% is only on Ubuntu 14.04 (Firefox))
Yes.
I reported the bug on Linux platform.
I tested with what I use i.e. Seamonkey and Firefox.

I am an end-user : I think that developers will easily see what happens and set the bug importance.

Comment 26

[newsmails]

@Xavier

As you can reproduce on Ubuntu it would be nice to provide a profile as asked by  alex_mayorga in comment 17.
Maybe it will help.

Comment 27

[Xavier Delgado]

Linux Euroka 3.13.0-62-generic #102-Ubuntu SMP Tue Aug 11 14:29:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 14.04 / Firefox 42 

report: http://people.mozilla.org/~bgirard/cleopatra/#report=ee22579895523a4981e6e0cf6889dcfff323726a

Comment 28

[Xavier Delgado]

Windows 8.1

Nightly 45.0a1 (2015-11-05)

http://people.mozilla.org/~bgirard/cleopatra/#report=136350fae13d9cbccdeb5f3756b35e89fd95fd0c

Comment 29

[Xavier Delgado]

Better Ubuntu 14.04 testing.

Nightly 45.0a1 (2015-11-08)

http://people.mozilla.org/~bgirard/cleopatra/#report=3220974a7c62845bfcfd0ab3bc3f519c7229ca57

Comment 30

[newsmails]

You asked for profiles. Several profiles on several systems were provided.
But it seems that nothing was done : the problem is still here...

Comment 31

[alex_mayorga]

¡Hola Benoit!

Could you please take a look at the profiles at https://bugzilla.mozilla.org/show_bug.cgi?id=1218169 and advise? 

¡Gracias!
Alex

Comment 32

[Benoit Girard (:BenWa)]

None of the profiles show any interesting activity. They only monitor graphics thread so it could be that work is happening in a background thread. To procedure we'd need to get a good process wide profile from a system profiler that would include all the threads in case this activity is coming from a background thread. Otherwise finding the element/source responsible by minimizing the page until the CPU usage goes away might help.

Comment 33

[laurens]

Same problem, high CPU usage on google results page.
OS X
Refresh
HW and smooth scrolling on/off: no difference
2014 Macbook Pro

When I disable Javascript on Google.com or when I minimise then CPU < 3%, else CPU >20% on the results page (static display)!

Same bug as: https://bugzilla.mozilla.org/show_bug.cgi?id=877597?

NB this has been a problem for me across 3 computers and several years... new profiles each time.
Application Basics
------------------

Name: Firefox
Version: 47.0.1
Build ID: 20160623154057
Update Channel: release
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:47.0) Gecko/20100101 Firefox/47.0
OS: Darwin 14.5.0 x86-64
Multiprocess Windows: 0/1 (Disabled)
Safe Mode: false

Crash Reports for the Last 3 Days
---------------------------------

All Crash Reports

Extensions
----------

Name: Firefox Hello
Version: 1.3.2
Enabled: true
ID: [e-mail]

Name: Multi-process staged rollout
Version: 1.0
Enabled: true
ID: [e-mail]

Name: Pocket
Version: 1.0.2
Enabled: true
ID: [e-mail]

Graphics
--------

Asynchronous Pan/Zoom: none
Device ID: 0x0a2e
GPU Accelerated Windows: 0/1 Basic (OMTC)
Supports Hardware H264 Decoding: Yes
Vendor ID: 0x8086
WebGL Renderer: Intel Inc. -- Intel Iris OpenGL Engine
windowLayerManagerRemote: true
AzureCanvasAccelerated: 1
AzureCanvasBackend: skia
AzureContentBackend: quartz
AzureFallbackCanvasBackend: none

Important Modified Preferences
------------------------------

browser.cache.disk.capacity: 358400
browser.cache.disk.filesystem_reported: 1
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 3
browser.download.importedFromSqlite: true
browser.places.smartBookmarksVersion: 7
browser.sessionstore.upgradeBackup.latestBuildID: 20160623154057
browser.startup.homepage_override.buildID: 20160623154057
browser.startup.homepage_override.mstone: 47.0.1
dom.apps.reset-permissions: true
dom.mozApps.used: true
extensions.lastAppVersion: 47.0.1
gfx.blacklist.direct2d: 3
media.gmp-gmpopenh264.abi: x86_64-gcc3-u-i386-x86_64
media.gmp-gmpopenh264.lastUpdate: 1469019114
media.gmp-gmpopenh264.version: 1.5.3
media.gmp-manager.buildID: 20160623154057
media.gmp-manager.lastCheck: 1469019113
media.gmp-widevinecdm.abi: x86_64-gcc3-u-i386-x86_64
media.gmp-widevinecdm.lastUpdate: 1469019117
media.gmp-widevinecdm.version: 1.4.8.866
media.gmp.storage.version.observed: 1
network.cookie.prefsMigrated: true
network.predictor.cleaned-up: true
places.history.expiration.transient_current_max_pages: 104858
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.12
Version in use: 4.12

NSS
Expected minimum version: 3.23 Basic ECC
Version in use: 3.23 Basic ECC

NSSSMIME
Expected minimum version: 3.23 Basic ECC
Version in use: 3.23 Basic ECC

NSSSSL
Expected minimum version: 3.23 Basic ECC
Version in use: 3.23 Basic ECC

NSSUTIL
Expected minimum version: 3.23
Version in use: 3.23

Experimental Features
---------------------

Comment 34

[Xavier Delgado]

WFM on Windows 10 x64

Nightly 50.0a1 (2016-07-20)

Comment 35

[ovidiu boca[:Ovidiu]]

Hi,

Do you still reproduce this issue? Please update to the latest FF version and see if you encounter any issue.

Comment 36

[Andre Klapper]

(In reply to ovidiu boca[:Ovidiu] from comment #35)
> Do you still reproduce this issue? Please update to the latest FF version
> and see if you encounter any issue.

@Ovidiu: Your comment does not make any sense. Did you actually read comment 33?

Comment 37

[ovidiu boca[:Ovidiu]]

Sorry for that, you are right. I wanted to ask if he can try with FF Nightly to see if he can reproduce it.

Comment 38

[laurens]

Same problem with FF 48.0 in Safe Mode.

Comment 39

[laurens]

(In reply to ovidiu boca[:Ovidiu] from comment #37)
> Sorry for that, you are right. I wanted to ask if he can try with FF Nightly
> to see if he can reproduce it.

Not tried with Nightly (this is a working system), but the problem persists unchanged in FF 48.0 release.

Comment 40

[Benoit Girard (:BenWa)]

Attachment: Screenshot 2016-08-02 14.06.17.png

Alright I looked more into this.

The google.fr page for me has a 'Rappel concernant les règles de confidentialité de Google' pannel. This has a CSS animated loading spinner that has an 'inherited visibility: hidden;'. We however keep re-calculating styles for this even though it's hidden.

We have some optimizations to fix some of these cases but they are not being applied here. We should find out why.

FWIW this page in chrome doesn't show this panel so I can't compare against Chrome.

Comment 41

[laurens]

If I allow the JS on google.fr then the CPU usage is high (30% when not doing anything, just displaying page). Sample the FF process shows a lot of mac_plugin_interposing_child_OnShowCursor (in XUL) calls. 
Maybe this helps? 

These calls are not there when JS is disabled.

Tnx

Comment 42

[Benoit Girard (:BenWa)]

If you want to verify you should set 'display: none' on the hidden spinner shown in the screenshot (inside the panel). This should drop down the CPU usage.

Comment 43

[laurens]

(In reply to Benoit Girard (:BenWa) from comment #42)
> If you want to verify you should set 'display: none' on the hidden spinner
> shown in the screenshot (inside the panel). This should drop down the CPU
> usage.

CPU usage now settles to about 6-7% and FF will go into App Nap from Google results page. (This quite a lot of wakeups/s before going to Appnap compared to Safari, but with animation display:none a lot seems to be fixed)

Comment 44

[Benoit Girard (:BenWa)]

How do you detect that something is in App Nap?

Comment 45

[laurens]

(In reply to Benoit Girard (:BenWa) from comment #44)
> How do you detect that something is in App Nap?

Activity Monitor - Energy Tab

https://support.apple.com/en-us/HT201464

Comment 46

[Benoit Girard (:BenWa)]

Attachment: Google5.html - (non-minimal) Reduction

Here's a fairly well reduced test case. Is there anything we can do to optimize or throttle this visibility: hidden; CSS animation? From what mstange tells me if this was visible this would be handled by OMTA and be throttled on the main thread. Perhaps we can throttle the case where it's also hidden?

I have a feeling this is a dupe of a power bug. But this being on the home page of google.fr makes it fairly important.

Comment 47

[Brian Birtles (:birtles)]

Yes, that sounds like bug 1237454. Hiro was working on it but I think he was looking for some help with detecting visibility of descendant elements.

Hiro, is this a dupe of bug 1237454? Can you reproduce? (It might be Linux-specific. The STR appear to be comment 12 + comment 0.)

Comment 48

[Hiroyuki Ikezoe (:hiro)]

Yes, this is absolutely a dupe of bug 1237454. Thanks BenWa for the test case, I could confirm easily.

I don't think this bug is specific for Linux platform, I guess it depends on machine power, I mean, high CPU usage or not, but anyway, the invisible animation consumes definitely on the main thread.

I am not sure to make this bug as a dupe of bug 1237454, so I am just adding bug 1237454 in dependency list for now.

Comment 49

[Hiroyuki Ikezoe (:hiro)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #48)

> I am not sure to make this bug as a dupe of bug 1237454,

Oops.  I meant that "I am not sure it's a good thing to make..".

Comment 50

[laurens]

Just wondering if there is any further input desired / needed for progress on this (I assume it effects every user with an OS X laptop?)

Comment 51

[njmcphail]

Hi. This is happening on Ubuntu on Firefox 51 (distribution and upstream versions) on the google.co.uk page. Interestingly, when logged into my google account this animation is not included and cpu usage is normal (see https://ovh.themcphails.uk/index.php/s/3AMFa2fO3eF5KlZ ). It only appears when not logged in (see https://ovh.themcphails.uk/index.php/s/GYkTSLuHM0wjm7N ).

Comment 52

[Flupp]

Attachment: google.de repaints

Firefox issues a lot of repaints while showing the search results.

I attached a video (“google.de repaints”) where I switch the “Show Paint” desktop effect in KDE three times on and off. Looking closely one might be able to recognize the redrawing of an invisible spinner in the middle of the page. I used a freshly created Firefox profile for this recoding.

Chromium does not show this redrawing behaviour.

PS: I also noticed excessive redrawing without visual changes on the members page of a group in GitLab. 

PPS: Bug 877597 seems to be related.

Comment 53

[decebalus]

As comment #40 describes, me and Tew could observe the hidden spinner of Privacy reminder having a significant impact on CPU usage, under Windows 10 and Windows 7 respectively (Platform specifies only Linux atm).

Privacy reminder (http://i.imgur.com/Jxa5EYq.png; localized for gooogle.country domains) on google search results page is the visual indicator required to reproduce this bug, = clean profile/cleared cookies necessary. That reminder is shown to google users till they confirm their agreement (or have confirmed before and log in), which is likely a significant population, even if mostly short-term (long-term in case of people who do not accept T&C).
firefox.exe --no-remote --profile "path_to_new_profile_to_create" http://www.google.de/?gws_rd=ssl#q=test   was a quick cmdline setup to repro (works with any country tld (~5 tested) to get Privacy reminder, but google.COM may not be showing it consistently?)
Per comment #42, document.getElementById("cnsm").style.display = "none";   fixes the high cpu usage by 'removing' the spinner better.

Depending on the firefox version, cpu usage drops down from 12% (with spinner) to 2% (spinner removed), from 16% (with spinner) to sub-1% (spinner removed), from 7% (with spinner) to 1% (spinner removed). The current ff54.0a1 Nightly was still affected.

Comment 54

[Flupp]

I can confirm decebalus’ observation that “better removing” the spinner helps.

I use the following uBlock Origin rule (you might have to adapt the URL to your country):

www.google.de###cnsm > g-loading-icon

This nicely works around the problem for now.

Comment 57

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is happening across platforms and all Google search pages independently of the language. It can only be avoided by signing in, as mentioned above.

I had 3 search pages open yesterday, and the battery got drained kinda quickly. I ended up quickly without any power left. :/ Knowing this problem, and the fact that Google forces us to stay logged in, is not that satisfying. Especially that I use containers to stop Google from tracking me.

Comment 58

[Tom]

(In reply to Flupp from comment #54)
> I use the following uBlock Origin rule (you might have to adapt the URL to your country):
> 
> www.google.de###cnsm > g-loading-icon
> 
> This nicely works around the problem for now.

Thanks for this hint. The same rule also works with AdBlock Plus. However, applying such rules should be a temporary solution. At the end, it would be much better to have such code suppressed by the browser engine. In this way, we would need less add-on resources, we could speed-up firefox even more and we would not waste electrical energy on useless css code.

Comment 59

[Brian Birtles (:birtles)]

Bug 1237454 (which should hopefully fix this) has been prioritized for Q1.

Comment 60

[Hiroyuki Ikezoe (:hiro)]

Could someone please try the binary in this try and see if what happens?
https://treeherder.mozilla.org/#/jobs?repo=try&revision=fbf16465620a8b9e1036901227bfe29a81381d3d

As far as I can tell the binary does not consume CPU so much in the attachment 8777050 [details] case, but unfortunately I can't confirm it on real google search results from here in Japan (even if I logged out) since I don't see any hidden animations on search results.

Direct links to the binaries;

- Linux x64 
 https://queue.taskcluster.net/v1/task/CkEggvbkRR6KPxDfpiVcZA/runs/0/artifacts/public/build/target.tar.bz2

- MacOSX
 https://queue.taskcluster.net/v1/task/WZzM0DlIRo2aun3HbAiNjA/runs/0/artifacts/public/build/target.dmg

- Win64
 https://queue.taskcluster.net/v1/task/H680XKeeTOmTu0B5jnm2zA/runs/0/artifacts/public/build/target.zip

Note that the binary are not PGO builds, so it should be bit slower than normal nightlies.

Thanks!

Comment 61

[21Naown]

I tested with a Google search query, as you requested.

Windows 7 64 bits: the CPU always consumes the same amount for me :(

I cannot try on other OSs at the moment, so I leave for other people.

Comment 62

[Hiroyuki Ikezoe (:hiro)]

(In reply to 21Naown from comment #61)
> I tested with a Google search query, as you requested.
> 
> Windows 7 64 bits: the CPU always consumes the same amount for me :(

Thanks! A bad news though.:/  Can you please attach the result page somehow here in this bug or somewhere else?  I'd like to see what's going on there by myself.  Thank you!

Comment 63

[21Naown]

Attachment: [FR] firefox - Recherche Google.htm

Comment 64

[21Naown]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #62)
> Thanks! A bad news though.:/  Can you please attach the result page somehow
> here in this bug or somewhere else?  I'd like to see what's going on there
> by myself.  Thank you!

Attached!

“Bon courage !” (= good luck but more formal :))

Comment 65

[Hiroyuki Ikezoe (:hiro)]

(In reply to 21Naown from comment #63)
> Created attachment 8942781 [details]
> [FR] firefox - Recherche Google.htm

Great! Thanks for the file!  Now I see the reason why the binary did not fix the CPU usage completely.

There are a bunch of invisible animations, most of them are throttled properly by the approach what I did take in the binary.  But there are two opacity animations that are not throttled at all, they still consume CPU because the animations don't specify 100% value in keyframes, it's bug 1419079.  So now I am convinced that the approach what I am going take is will fix this Google issue partially, to fix the issue completely we need to fix bug 1419079 too.

Comment 70

[puxplaying]

> As far as I can tell the binary does not consume CPU so much in the
> attachment 8777050 [details] case, but unfortunately I can't confirm it on
> real google search results from here in Japan (even if I logged out) since I
> don't see any hidden animations on search results.



Hello hard working people,
I can also confirm this problem on the google search.

To reproduce it I use PIA VPN and choose the Switzerland server, because it seems only a few countries of the EU are affected.
Also my browser profile is set to German which brings me to a German google search where this g-loading-icon is always present and increases the CPU load.

My report about it on the Manjaro Linux forum:
https://forum.manjaro.org/t/firefox-google-search-high-cpu-usage-workaround-poll/46589

Hope that helps a bit!

Comment 71

[Hiroyuki Ikezoe (:hiro)]

Now bug 1430884 has been landed on mozilla-central and a new nightly including the fix has been released (buildid: 20180625220119).  I am pretty sure all animations in two examples in comment 46 and comment 63 are properly optimized.  Could somebody check the behavior on a real google result page?

Comment 72

[21Naown]

Comment 46, comment 63, and a real google result page: no more "Recalculate Style"/"Apply Style Changes" (from Developer Tools - Performance) with Firefox Nightly 20180626220124, so the CPU utilisation is nearly identical to Firefox 60 which has the animations removed (= ~1%)!

Comment 73

[Hiroyuki Ikezoe (:hiro)]

Thank you, 21Naown!  I am going to mark this bug as fixed.

Comment 74

[laurens]

Regression? 
Macbook Air HD 3000 graphics (recommended performance settings in FF62.0.2) macOS 10.13.6

https://www.google.com/search?client=firefox-b-ab&q=nothing

No addons
FF62.0.2: CPU usage logged in google results page: 10%
FF62.0.2: CPU usage not logged in google results page: 30%
Safari: CPU usage <3%


fans spinning like crazy just showing 2 google results pages (!)

Comment 75

[Hiroyuki Ikezoe (:hiro)]

laurens, the bug (bug 1430884) landed in Firefox 63, not in Firefox 62.

Comment 76

[21Naown]

Would it be possible Firefox ESR benefits from your fix without waiting Firefox ESR 68?

Comment 77

[Hiroyuki Ikezoe (:hiro)]

I am afraid I don't think it's possible.  The fix for bug 1430884 changed lots of codes.