Comment 6 for bug 1856624

Revision history for this message
In , Timj-8 (timj-8) wrote :

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:
  npm i electron@4 && node_modules/electron/dist/electron

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.
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:performance` 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.

Expected results:

A) FF CPU usage should not be triggered by libchromiumcontent using applications.
B) Tab "about:performance" should actually indicate where the CPU cycles are being wasted.