1580016 - High CPU Usage of "Web Content" and "WebExtensions" when chrome or VSCode open

Status: RESOLVED DUPLICATE of bug 1495900

(Core :: Graphics: Text, defect, P3)

Description

[victor_ls_6]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

I found the bug using VSCode, but it also shows up with chrome. If Firefox is running and I start VSCode, the first time it's fine, but after closing VSCode, every time I start it again, all Web Content and WebExtensions processes hog up CPU until it's on 100%, and it takes about a minute to recover. I'm on Debian 9, but according to this post (https://superuser.com/questions/1467253/ubuntu-18-04-web-content-webextension-high-cpu-usage), the same thing happens in Ubuntu, with even higher specs than mine. RAM usage is fine.
I'm on an Intel i5 8250-U CPU with 16GB of RAM.

Actual results:

My machine becomes unusable for a minute or so, and it's consistent every time I try this. The issue doesn't happen if Firefox is not running, and it's not solved by disabling extensions either. I didn't have this problem before, I've been using the Developer Edition of Firefox for a couple of years.

Expected results:

The CPU usage shouldn't go up.

Comment 1

[Marcela (Please NI request to Brindusa Tot)]

I'm assigning a component in order to involve the development team to have a proper review on the issue

Comment 2

[Stéphane Roucheray]

I am on Ubuntu 18.04.3 LTS and see similar problems. As a web developer I usually use Firefox in conjunction with VSCode and Chrome.
It seems that when VSCode TSServer starts (when opening a new typescript project) or when Chrome launches (while launching unit tests), Firefox which is already started, starts using as much as CPU it can for some times.

Comment 3

[Chaos]

I can confirm this issue in Xubuntu 18.04.
Is not only frustrating to have this problem everyday while coding, but it also harms hardware by making cpu work at full speed.
Please, fix this issue when you can.

Comment 4

[csuzdy]

Ubuntu 18.04.3 LTS user here.
Firefox version: 69.0.1
Device: Thinkpad T420
If I run firefox and chrome (or VSCode, that uses chrome's engine internally) in parallel, Firefox starts using all the CPU cores with 100% utilization.
It is very annoying, as Firefox is my primary browser and I want to use VSCode for development.

Comment 5

[Markus Stange [:mstange]]

Could you use perf to profile the Firefox process with the high CPU usage and share it via profiler.firefox.com? That might give us more insight into what's happening here.
Please follow these instructions: https://perf-html.io/docs/#/./guide-perf-profiling

Comment 6

[csuzdy]

Here is the perf:
I started Firefox and Chrome a few secs later.
https://perfht.ml/31Mvy15

Another observation: when I start Chrome/VSCode first and then Firefox, everything work fine. So this can be a workaround until the fix is out.

Comment 7

[Markus Stange [:mstange]]

Thanks! Can you check whether Firefox Nightly has the same problem? And could you then capture two profiles using perf, on Nightly:
One without Chrome running, after Firefox has settled down and is idle. Then launch Chrome and capture another profile.
It's important to let Firefox settle first so that it's easier to separate Chrome-triggered activity from regular startup activity.
Also, once you have the perf profiles, could you capture two more profiles, this time using the Gecko Profiler add-on instead of perf? See https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem for instructions.
Having all four profiles (perf idle, regular idle, perf with Chrome, regular with Chrome) should allow us to find the cause for this.

From the perf profile, it looks like there is a lot of activity on the WebExtension process main thread and on a content process main thread. This activity only starts 4 seconds into the profile. I presume that that's when Chrome was started.

Comment 8

[csuzdy]

The problem can be reproduced with nightly (firefox-71.0a1.en-US.linux-x86_64)
There are multiple processes, so I chose this, one of which had high CPU load:
csuzdy 18960 5.8 1.0 2564936 81052 pts/1 Sl+ 20:19 1:38 /home/csuzdy/Desktop/packages/firefox_nightly/firefox-bin -contentproc -childID 3 -isForBrowser -prefsLen 7049 -prefMapSize 202298 -parentBuildID 20191004094656 -greomni /home/csuzdy/Desktop/packages/firefox_nightly/omni.ja -appomni /home/csuzdy/Desktop/packages/firefox_nightly/browser/omni.ja -appdir /home/csuzdy/Desktop/packages/firefox_nightly/browser 18797 true tab

Idle (pref): https://perfht.ml/2AJ2iwd
Idle (regular): https://perfht.ml/33dUajN

Busy (pref): https://perfht.ml/30HfwnO
Busy (regular): https://perfht.ml/30NusRt (It contains a little idle part in the beginning. I could not start the profiler during the high-CPU phase, the page was unresponsive. So I started it before and stopped after the high-CPU phase.)

Comment 9

[Markus Stange [:mstange]]

Thank you!

Unfortunately, the information that I'm looking for remains elusive.
In the Busy (perf) profile, there's clearly a lot of activity on the main thread of process 18960, but all symbols are [unknown]. I had hoped that profiling Nightly would let us get proper symbols here instead of [unknown], but that doesn't seem to be the case.
In the Busy (regular) profile, I do not see any activity on any of the main threads.

Can you try to get another Busy (regular) profile? Also, can you describe which part of the UI is unresponsive? Is the browser UI at the top unresponsive, too? Does clicking the add-on button not open the panel? Or does nothing load in the panel? Please use the panel buttons to start/stop the profiler, not the keyboard shortcuts, because the keyboard shortcuts get delayed by unresponsive content processes if focus is inside content.

Comment 10

[csuzdy]

Both the panel buttons and the content area is unresponsive. If I click on the profiler button, it opens a little white bubble, but the content of the profiler settings does not load.

I tried to reveal the unknown stack frames, so I installed libfreetype6-dbgsym_2.8.1-2ubuntu2_amd64.ddeb. I hope it helps.
Here is the new perf profile: https://perfht.ml/2LLSl7G
The new regular profile: https://perfht.ml/35bNh3Z, https://perfht.ml/2AICAIh

Comment 11

[Daniel Holbert [:dholbert]]

This looks like we're spending a lot of time in font loading code -- the content processes in https://perfht.ml/37vf4O9 show many seconds spent in "FcInitReinitialize". I wonder if Chrome and/or VSCode install some fonts in a way that prompts us to reinitialize our font library, or something like that?

jfkthame, do you know what might be going on here?

Comment 12

[Jonathan Kew [:jfkthame]]

This sounds like bug 1495900. What version of fontconfig is present on the system where this happens? Updating to fontconfig 2.13 or later should help.

Comment 13

[csuzdy]

Thanks Jonathan for the tip, I manually installed fontconfig 2.13 packages and it helped.
On Ubuntu:

sudo dpkg -i libfreetype6_2.9.1-4_amd64.deb 
sudo dpkg -i fontconfig-config_2.13.1-2ubuntu2_all.deb 
sudo dpkg -i libfontconfig1_2.13.1-2ubuntu2_amd64.deb

Comment 14

[Jonathan Kew [:jfkthame]]

OK, that confirms this is the same issue as bug 1495900; closing as a duplicate.

(Although much of the problem seems to be in fontconfig, it would still be nice if we could find a workaround so that Firefox users with older fontconfig versions don't suffer this issue.)

Comment 15

[mac_man2008]

The problem persists. At the moment I only have Firefox running with just one tab and the Web Extension process is taking 100% of one of the 8 threads of my Intel(R) Core(TM) i7-8550U CPU @ 1.80GH.

libfreetype, fontconfig and libfontconfig are already at newer or same version as those recommended by csuzdy on comment #13

Firefox 94.0
ID build 20211028161635
ID distribuzione mint
User agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0
SO Linux 5.4.0-90-generic #101-Ubuntu SMP Fri Oct 15 20:00:55 UTC 2021
Tema SO Mint-Y-Aqua / Adwaita-dark

Running Linux Mint 20.2 with Mate 64-bit

(In reply to csuzdy from comment #13)

Thanks Jonathan for the tip, I manually installed fontconfig 2.13 packages and it helped.
On Ubuntu:

sudo dpkg -i libfreetype6_2.9.1-4_amd64.deb 
sudo dpkg -i fontconfig-config_2.13.1-2ubuntu2_all.deb 
sudo dpkg -i libfontconfig1_2.13.1-2ubuntu2_amd64.deb

Comment 16

[Benjamin Melançon]

Found this by searching only for "WebExtensions 100% CPU" (and noticed in my browser history i had searched before), and lo and behold i am also using VSCodium while Firefox is running. In my case the computer stays usable but my battery life is reduced by 75% (four hours to one), and it's been five minutes and has not stopped.

My fontconfig is already at 2.13:

fontconfig/testing,now 2.13.1-4.4 amd64 [installed,automatic]

Debian 11, Firefox 94.0, and VSCodium Version: 1.65.2 (Electron: 13.5.2, Chromium: 91.0.4472.164, OS: Linux x64 5.16.0-3-amd64)