Closed Bug 1646600 Opened 4 years ago Closed 1 year ago

Firefox becomes unusable while on a zoom call under mysterious circumstances


(Core :: Performance, defect, P3)

78 Branch





(Reporter: bas.schouten, Unassigned)


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.

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

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

Flags: needinfo?(bas)

This profile comes from Andrew Overholt:

Flags: needinfo?(bas) → needinfo?(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.

Flags: needinfo?(overholt)
Severity: -- → S3

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

15564: ->
8324: idle?
4164: idle?
11596: 0,5 sec network wait on dispatch InputStreamReady
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.

Component: General → Performance

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

Flags: needinfo?(overholt)
Flags: needinfo?(bas)

In the profiler there is a looong parent process hang: ContentParent::KillHard
And that reminds me of and
That latter is fixed for 79. Could you try 79?

Severity: S3 → S2
Priority: -- → P3

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

Flags: needinfo?(overholt)

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

Flags: needinfo?(overholt)

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

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.

Flags: needinfo?(overholt)

Bas, do you still experience this problem?

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

Closed: 1 year ago
Flags: needinfo?(bas)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.