1646600 - Firefox becomes unusable while on a zoom call under mysterious circumstances

Status: RESOLVED WORKSFORME

(Core :: Performance, defect, P3)

Description

[Bas Schouten (:bas.schouten)]

For the second time now, I've had a Firefox Beta session become mostly unresponsive while I had an active zoom call with a fair amount of participants, after restarting my session in an attempt to debug the issue disappeared. I realize this isn't the most useful bug in itself but I believe this is the same issue Andrew Overholt has been seeing so I'm concerned this is more common than we think, and it is quite severe. We also have profiles of what we believe may be the issue, but it didn't immediately point out the issue.

Comment 1

[Gian-Carlo Pascutto [:gcp]]

Can you attach some of the profiles to have another pair of eyes on it?

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)

Can you attach some of the profiles to have another pair of eyes on it?

NI Bas for comment 1. :)

Comment 3

[Bas Schouten (:bas.schouten)]

This profile comes from Andrew Overholt: https://share.firefox.dev/30xsfNz

Comment 4

[Andrew Overholt [:overholt]]

I'm not sure what else I can add that's useful. Bas and I have been seeing this during a trivia game we've been playing. Our team uses Discord for audio communication (via WebRTC) while having Zoom open for video+audio with the main game. It's not 100% reproducible and when I took a Windows WPR trace I didn't get anything interesting.

Comment 5

[Jens Stutte [:jstutte]]

As I should triage this bug, I tried to make some sense of the profile. I see the following processes/domains:

16748: discord.com
14948: google.com
15192: mozilla.org
15564: mike.kaply.com -> youtube.com
10012: slack.com
8324: idle?
4164: idle?
11596: 0,5 sec network wait on dispatch InputStreamReady
14308: facebook.com
12732: idle?
17164: idle?

Talking with :overholt, it is not clear, what those idle? processes were supposed to handle. Their being idle all the time might indicate a deadlock?
In any case we do not have many elements to move this forward in a meaningful way, for now let's try to get some more analysis from performance perspective.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Bas, Andrew, so are you using Zoom in the browser? Or does the Zoom program itself affect to Firefox?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

In the profiler there is a looong parent process hang: ContentParent::KillHard
And that reminds me of https://bugzilla.mozilla.org/show_bug.cgi?id=1626789 and https://bugzilla.mozilla.org/show_bug.cgi?id=1637048
That latter is fixed for 79. Could you try 79?

Comment 8

[Jens Stutte [:jstutte]]

(In reply to Olli Pettay [:smaug] from comment #6)

Bas, Andrew, so are you using Zoom in the browser? Or does the Zoom program itself affect to Firefox?

I talked with Andrew before, he used the zoom app alongside the browser. Not sure about Bas, though.

Edit (after reading bug 1626789 a bit): Which might be a similar scenario, the zoom app is creating quite some pressure both on CPU and GPU even on fast machines. FWIW: I noticed also, that sometimes I had to raise the priority of the zoom process under Windows in order to not have it stuttering while using the browser (especially with gdoc) and that the browser become slower, too (but not completely unusable, so I blamed zoom for it, not Firefox).

Comment 9

[Jens Stutte [:jstutte]]

:bas, :overholt, I had now a similar issue. By chance you are using a Lenovo X1 Carbon under Windows ? I had for some days zoom stuttering while using Firefox. I always looked only at the high memory consumption and CPU % in the task manager. It turned out, that I should have looked at the CPU clock instead, as my fan did not spin at all and the CPU/GPU started thermal throttling, it seems. I did the following (not sure what helped out of these):

• blowing several times through the fan in- and outtakes
• installed the tool SpeedFan (which does not recognize the fan at all, so I doubt it did anything)
• Went once in the BIOS without changing any settings, though. After that reboot, the fan was heard.
  By now it turned spinning. You can easily hear, if the fan spins, so take note for the next time...

I vaguely remember, that there was some firmware/BIOS upgrade not very long ago, this might be related or not.

Comment 10

[Nils Ohlmeier [:drno]]

Andrew mentioned this bug to me today. And it reminded me on a problem I ran into last week with Fx 80 on Mac.

I have Fission enabled and I ran a local Fx build on the same machine. This combination resulted in Firefox only showing in Mac beach ball and I could only 'force kill' it.
According to the OSX activity monitor the Fx parent process is unresponsive in that situation. And all the other Fission content processes are consuming around 10% or so CPU time. I did take a spin dump, but I didn't notice anything standing out in there. It looked like a lot of processes and threads waiting for semaphores etc.

This whole scenario was reproducible for me. And I didn't ran any WebRTC at the time. So the problem is probably more like https://bugzilla.mozilla.org/show_bug.cgi?id=1626789 like smaug pointed out in comment #11 already.

But I'm wondering if what is experienced here is somewhat similar in that the Zoom desktop client consumes so much CPU time, that Firefox parent process doesn't get enough CPU time any more and then slows down all of Firefox.

Comment 11

[Andrew Overholt [:overholt]]

I'll watch the CPU speed and listen for the fan the next time this happens. FWIW I do see a11y enabled in about:support (Surface Laptop with a touchscreen); I have no IMEs installed AFAIK.

Comment 12

[Pascal Chevrel:pascalc (PTO until April 26)]

Bas, do you still experience this problem?

Comment 13

[Bas Schouten (:bas.schouten)]

I have not seen this for 6 months now. Closing.