Closed Bug 1580016 Opened 3 years ago Closed 3 years ago

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


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

70 Branch



Performance P3


(Reporter: victor_ls_6, Unassigned, NeedInfo)


(Keywords: perf:responsiveness)

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

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

Component: Untriaged → Performance
Product: Firefox → Core

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.

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.

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.

Could you use perf to profile the Firefox process with the high CPU usage and share it via That might give us more insight into what's happening here.
Please follow these instructions:

Flags: needinfo?(victor_ls_6)
Ever confirmed: true
Priority: -- → P3
Whiteboard: [qf]

Here is the perf:
I started Firefox and Chrome a few secs later.

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.

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

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

Busy (pref):
Busy (regular): (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.)

Flags: needinfo?(csuzdy)

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.

Flags: needinfo?(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:
The new regular profile:,

Flags: needinfo?(csuzdy)

This looks like we're spending a lot of time in font loading code -- the content processes in 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?

Component: Performance → Graphics: Text
Flags: needinfo?(jfkthame)
Whiteboard: [qf] → [qf:p3:responsiveness]

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.

Flags: needinfo?(jfkthame)

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

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

Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1495900

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
Performance: --- → P3
Whiteboard: [qf:p3:responsiveness]

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)

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