Firefox freezes temporarily at 100% CPU when Chromium is opened
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Invalid
|
Medium
|
|||
firefox (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
When Firefox is open, and I open Chromium, many features of Firefox fail to work for several seconds. (To reproduce, start with neither Firefox nor Chromium open; open Firefox, and allow one or more web pages to load; then open Chromium; the issue starts a second or two after Chromium is opened.) This is a temporary issue, lasting for several seconds; the length of time it lasts appears to depend on how many open tabs have been viewed since Firefox opened (on my computer, around 10 seconds with 1 tab having been viewed, around a minute with 10 tabs having been viewed). This reproduces even when running Firefox as `firefox -safe-mode`.
While the issue is ongoing (i.e. starting around a second after Chromium is open, and persisting for typically tens of seconds), some features of Firefox work, but most do not:
- Scrolling the current tab short distances succeeds, showing the expected text on the page.
- Scrolling the current tab long distances (several screeenfuls) causes the page to be "cut off" past a certain point, with only a blank background rendering.
- Moving the mouse cursor over a link does not change the mouse cursor (expected behaviour, and behaviour while the issue is not ongoing, is for it to change to a hand shape).
- Changing tab causes the resulting page not to display: rather, a grey background is displayed, and sometimes a loading spinner.
- Changing tab back then causes the original page not to render, as if it were new, despite the fact it was correctly displayed earlier.
- The address bar functions as normal; the issue does not appear to affect address bar functionality.
Additionally, while the issue is ongoing, Firefox uses 100% CPU.
At some point after the issue in question starts, it stops, and all Firefox features return to normal (including any missing or incorrectly rendered page content, which renders again when the issue ends).
The trigger is specifically the act of opening Chromium: Firefox can function just fine once the issue ends, even if Chromium is still open, and functions just fine if Chromium is opened first.
I have an (unconfirmed) theory that opening Chromium is causing some operation within Firefox to become very slow, using up all the CPU time, and the other observed misbehaviours within Firefox are a consequence of how slowly it is running; however, I've listed them all anyway in case it provides clarity into what the specific nature of the bug is.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: firefox 71.0+build5-
ProcVersionSign
Uname: Linux 5.0.0-37-generic x86_64
AddonCompatChec
ApportVersion: 2.20.9-0ubuntu7.9
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
BuildID: 20191205184924
Channel: Unavailable
CurrentDesktop: X-Cinnamon
Date: Tue Dec 17 00:29:10 2019
ExecutablePath: /usr/lib/
ForcedLayersAccel: False
IfupdownConfig:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
IncompatibleExt
English (South Africa) Language Pack - <email address hidden>
Français Language Pack - <email address hidden>
English (GB) Language Pack - <email address hidden>
Default - {972ce4c6-
InstallationDate: Installed on 2019-11-11 (35 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
IpRoute:
default via 192.168.1.1 dev wlp2s0 proto dhcp metric 600
169.254.0.0/16 dev wlp2s0 scope link metric 1000
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.101 metric 600
MostRecentCrashID: bp-935fd166-
PrefErrors: Unexpected character ',' before close parenthesis @ /usr/lib/
PrefSources: prefs.js
ProcEnviron:
LANGUAGE=en_GB:en
PATH=(custom, user)
XDG_RUNTIME_
LANG=en_GB.UTF-8
SHELL=/bin/bash
Profiles: Profile0 (Default) - LastVersion=
RunningIncompat
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/30/2019
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.5.1
dmi.board.name: 0DDKKC
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 10
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.family: Inspiron
dmi.product.name: Inspiron 3583
dmi.product.sku: 08CA
dmi.sys.vendor: Dell Inc.
Changed in firefox: | |
importance: | Unknown → Medium |
status: | Unknown → New |
Changed in firefox: | |
status: | New → Invalid |
Created attachment 9078136
Screenshot from 2019-07-15 15-33-31.png
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
1. Start Firefox-68.0 (fresh profile) on Ubuntu 18.04.2 LTS with X11 on Linux 4.15.0-50-generic x86_64. (Note, this behaviour has also been observed with FF-67 versions.)
2. Start an application with libchromiumcontent >= 69.0.3497.128, e.g. by starting electron-4 (v69.0.3497.128) or electron-5 (v73.0.3683.121) or gooogle-chrome (v75.0.3770.100). Example: electron/ dist/electron
npm i electron@4 && node_modules/
3. The second application can be closed immediately, starting it is enough already to trigger FF.
Note, libchromiumcontent v66.0.3359.181 (from electron-3) does *NOT* trigger FF.
Actual results:
Firefox uses up *all* CPU cores (8 here) at 100% for several seconds, observable e.g. via `htop` with thread view. ce` opened during the overload situation, it will display *only* the "Task Manager" row, until it recovers from the overload situation, after that point it also lists the other rows for additional tabs again.
Even exiting the libchromiumcontent using application immediately doesn't cure FF from overloading all CPU cores for several more seconds.
If you happen to have `about:performan
Expected results:
A) FF CPU usage should not be triggered by libchromiumcontent using applications. ce" should actually indicate where the CPU cycles are being wasted.
B) Tab "about:performan