Closed Bug 1218169 Opened 9 years ago Closed 6 years ago

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

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
41 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: newsmails, Assigned: hiro)

References

Details

(Keywords: perf, Whiteboard: [bugday-20151026])

Attachments

(6 files)

bugFF1.jpg
274.65 KB, image/jpeg
Details
red needed to reproduce
275.51 KB, image/jpeg
Details
Screenshot 2016-08-02 14.06.17.png
66.43 KB, image/png
Details
Google5.html - (non-minimal) Reduction
9.12 KB, text/html
Details
google.de repaints
4.75 MB, video/webm
Details
[FR] firefox - Recherche Google.htm
376.29 KB, text/html
Details
Attached image 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%.
OS: Unspecified → Linux
Hardware: Unspecified → x86
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
Flags: needinfo?(alertesmails)
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")
"
Flags: needinfo?(alertesmails)
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 ?
¡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
Flags: needinfo?(alertesmails)
Whiteboard: [bugday-20151026]
Must I test with a nightly build as said in the link or with my version ?
Flags: needinfo?(alertesmails)
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...
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/
Component: Untriaged → General
Product: Firefox → Core
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 ?
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 ?
¡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...
Flags: needinfo?(n.nethercote)
(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)
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.
Attached image red needed to reproduce — 

    
    

    
  
I don't see anything notable in the profiles, but I'm terrible at reading those kinds of profile. Sorry!
Flags: needinfo?(n.nethercote)

    
    

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

Nothing weird.

    
    

    
  
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)

    
    

    
  
¡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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(xavier.delgado)
Summary: 60% CPU usage on idle on the empty www.google search page → High CPU usage on idle empty www.google.fr French search page

    
    

    
  
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 ;) )
Flags: needinfo?(xavier.delgado)

    
    

    
  
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

    
    

    
  
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%

    
    

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

    
    

    
  
Not only Seamonkey. Chrome and IE.

    
    

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

    
    

    
  
Windows 8.1 / Firefox 42

Changes from ~6% to ~16%

    
    

    
  
> (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.
Flags: needinfo?(alertesmails)

    
    

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

    
    

    
  
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

    
    

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

    
    

    
  
¡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
Flags: needinfo?(bgirard)

    
    

    
  
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.
Flags: needinfo?(bgirard)

    
    

    
  
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: loop@mozilla.org

Name: Multi-process staged rollout
Version: 1.0
Enabled: true
ID: e10srollout@mozilla.org

Name: Pocket
Version: 1.0.2
Enabled: true
ID: firefox@getpocket.com

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

    
    

    
  
WFM on Windows 10 x64

Nightly 50.0a1 (2016-07-20)

    
    

    
  
Hi,

Do you still reproduce this issue? Please update to the latest FF version and see if you encounter any issue.
Flags: needinfo?(alertesmails)

    
    

    
  
(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?
Flags: needinfo?(alertesmails)

    
    

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

    
    

    
  
Same problem with FF 48.0 in Safe Mode.

    
    

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

    
    

    
  


  
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.
Summary: High CPU usage on idle empty www.google.fr French search page → Hidden CSS Animated spinner causes high idle CPU usage on www.google.fr French search page
Component: General → Layout

    
    

    
  
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

    
    

    
  
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.

    
    

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

    
    

    
  
How do you detect that something is in App Nap?

    
    

    
  
(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

    
    

    
  


  
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.
Flags: needinfo?(bbirtles)

    
    

    
  
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.)
Flags: needinfo?(bbirtles) → needinfo?(hiikezoe)

    
    

    
  
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.
Depends on: 1237454
Flags: needinfo?(hiikezoe)

    
    

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

    
    

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

    
    

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

    
    

    
  

      
      
      
      

        Attached video
          
        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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.
Keywords: perf
OS: Linux → All
Hardware: x86 → All
Summary: Hidden CSS Animated spinner causes high idle CPU usage on www.google.fr French search page → Hidden CSS animated spinner causes high CPU load on Google search pages if not logged in

    
    

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

    
    

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

    
    

    
  
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!

    
    

    
  
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.

    
    

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

    
    

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

    
    

    
  
(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.
Depends on: 1419079

    
  
Depends on: 1430884

    
    

    
  
> 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!

    
    

    
  
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 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%)!

    
    

    
  
Thank you, 21Naown!  I am going to mark this bug as fixed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED

    
  
Assignee: nobody → hikezoe

    
    

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

    
    

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

    
    

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

    
    

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

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: