274.65 KB, image/jpeg
275.51 KB, image/jpeg
66.43 KB, image/png
9.12 KB, text/html
4.75 MB, video/webm
376.29 KB, text/html
Created attachment 8678567 [details] 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%.
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") "
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
Must I test with a nightly build as said in the link or with my version ?
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...
(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.
I don't see anything notable in the profiles, but I'm terrible at reading those kinds of profile. Sorry!
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
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 ;) )
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)
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.
@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
Windows 8.1 Nightly 45.0a1 (2015-11-05) http://people.mozilla.org/~bgirard/cleopatra/#report=136350fae13d9cbccdeb5f3756b35e89fd95fd0c
Better Ubuntu 14.04 testing. Nightly 45.0a1 (2015-11-08) http://people.mozilla.org/~bgirard/cleopatra/#report=3220974a7c62845bfcfd0ab3bc3f519c7229ca57
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
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.
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.
(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?
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.
Created attachment 8777027 [details] 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.
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
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
Created attachment 8777050 [details] 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.
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
(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 ).
Created attachment 8837193 [details] 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.
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
> 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
Last Resolved: 4 months ago
Resolution: --- → FIXED
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.
You need to log in before you can comment on or make changes to this bug.