Firefox keeps crashing, reloading every five seconds or so

This is happening on when there is more than one person connected. Tested with Firefox 94.0.1 on MacOS and Firefox Extended Support Release 78.15.0esr on Debian Stable.

It was a change that happened on in the last 24 hours as Firefox was working on the morning of November 10th.

I ruled out a few things:

  • The version of Firefox did not get updated.
  • I tried with and without the OpenH264 plugin and it did not make a difference.
  • Clearing cookies and other private data did not help.
  • Creating a completely new user account and running Firefox from within that account failed in the exact same way.

I just tested with Firefox 93.0 on MacOS and I didn’t observe this behavior. So, if there’s indeed an issue, it would suggest it’s between Firefox 94 and Jitsi.

I did observe though that virtual backgrounds set in Firefox did not show up on the other user’s view of the participant. This is on (alpha works fine).

Same problem looks happen on my environment:

  • Windows 10 Pro 21H1
  • Firefox 94.0.1 (64bit)

And this doesn’t happen on Google Chrome 95.0.4638.69.

Same problem looks happen on my environment:

  • Ubuntu 21.10
  • Firefox 94.0 (64bit)

And this doesn’t happen on Google Chrome 93.0.4577.63.

1 Like

Same problem looks happen on my environment:

  • MacOS BigSur 11.3
  • Firefox 93.0 (64bit)

And this doesn’t happen on Google Chrome 95.0.4638.54.

Similar problem on:

  • Windows 10 Pro
  • Firefox 94.0.1

My problem isn’t exactly crashing and reloading the conference, however Firefox doesn’t send or receive any video from other participants. and work ok tho.

I can confirm I’m seeing the same behaviour (FF 94.0.1, MacOS).

Console logs show ICE failure each time before the session reloads:

I don’t know if this message helps but I can confirm that I have seen this exact behavior this morning with Firefox 94.0.1 on a Debian system. When switching to Chrome, rather than getting in and then it continually reloading, it just gave an error.

Fellow meeting attendees on Macs and Windows did not seem to be affected. Mobile jitsi meet application 21.4.1 seems to be uneffected.

Just retested and it is still an issue on for Firefox 94.0.1.

@damencho Is this on your radar?

Yep, it is. Thanks for the report to all.

1 Like

The fix is rolling out at the moment, it make take some time (hours) as we do not want to break existing meetings.


This was caused by Firefox being more strict when it comes to parsing ICE candidates. Additionally to the above mentioned feature roll back we have a PR now fix: use dummy values for raddr and rport instead of dropping them. by nils-ohlmeier · Pull Request #1759 · jitsi/jitsi-videobridge · GitHub to fix this going forward.

1 Like

Is this something which could cause problems at stand-alone installations as well, or is this issue just related to things you guys have done on Because I am getting reports from some users internally who use FF 94 and experience ‘problems’ on ‘some’ meetings. Just curious if this is something I should ignore for now, or if I should make myself ready to upgrade all installations as soon as fixes are applied in a new release. Thanks!

for me the problem is still there. I’m using Firefox 94.0.1 on the newest Ubuntu version (21.10).
I don’t see my clients video, not hear him, he doesn’t hear me. Sometimes it starts to flicker on and off (keeps reloading the page).
It’s most of the times, enough that I regularly have to switch to Google meet after giving it a few tries,… :frowning:
From @drno I got the impression that it was fixed, but it persists for me.
Help would be very much appreciated
I love Jitsi

How awful. I love Jitsi, too, but it’s disappointing that it has been so unstable recently. This isn’t a fix, but have you tried Firefox’s Extended Support Release? I’m using Firefox 78.15.0esr (64-bit) on Debian and haven’t been having this bug recently.

This is an unfair determination. The problems that people have been reporting with using Firefox lately have to do with Firefox bugs, not Jitsi. These bugs have been raised with the Mozilla team, they have to provide the fixes. Some weeks back, it was some restrictions that the Google team placed on Chrome that caused issues with Jitsi. There was immediate pushback from the Jitsi team (and others) and those restrictions were lifted. Safari has its own shortcomings. It’s important to bear in mind that Jitsi is based on WebRTC. WebRTC is primarily dependent on browsers and there will likely be as many problems as there are browsers. Browsers are constantly updating their code and that means there’s always opportunity for something (new) to break. It is wrong to blame browser issues on Jitsi.


So on we rolled out a new release with a new option for trickle ICE turned on, which we thought would work. It turned out that this new option was not compatible with Firefox ICE candidate parser. The immediate fix @damencho mentioned was to turn off that new config option on the servers. The fix I referred to is a code fix, which allows to turn that new option in Jitsi on while still working with Firefox.

None of this means that Jitsi is now going to be working great with Firefox. Or that Jitsi is going to be bug free now when it comes to working with Firefox.

And just avoid confusion: that new option in Jitsi would have not worked with any version of Firefox down to probably Firefox 50 or something like that. I don’t have a good explanation why it was working for some folks, but ICE is unfortunately depending on a lot of things and is racy by nature.

As a former Firefox developer I try to improve interoperability between Jitsi and Firefox when ever I can. And yes I wish it would be better already.
The Mozilla folks have just landed a big update of the libwebrtc copy inside Firefox. Hopefully this will improve things in the long run. If you want to help testing download Firefox 96, which is currently the Firefox Nightly channel, and give it a try.


I am also biased and would prefer to blame the browsers when things go wrong. But, it is equally wrong to blame browsers when they are not at fault. Jitsi has rolled out changes that broke first Chromium (still not fixed) and then Firefox (fixed for me, but apparently not everyone). My browsers did not change. (Yes, I checked the change logs.)

I run the “stable” version of Debian GNU/Linux which comes with stable browsers which do not get updated except for security patches. You may have noticed that my Firefox version number is not 95, it is 78. Likewise, I’m running Chromium 90 and have been since April. It worked for months with Jitsi Meet until around Halloween when it started exploding with an instant “Oh Snap!” error as soon as someone else joins the room.

I was told that the WebRTC crashes do not occur in the latest Chrome/ium. That’s not a workable solution for me, so my plan has been to just use Firefox ESR until the bug gets fixed.

And, for a while, Firefox was actually better. Jitsi Meet had been crashing daily on both Google Chrome and Chromium on my machine if I leave a room open with only myself in it. I believe it was triggered by a new participant joining, but I do not know. Firefox has had no such problem. I’ve had a room open for days, with occasional visitors, and it has been rock solid. (Well, other than the known bugs with screensharing not re-enabling the video and having to reload; but I’m pretty sure that is a browser issue.).

I do not like to complain about such a great product, but I do want to give constructive feedback. I wish I knew better how to debug Jitsi so that, even if I can’t fix the bugs, at least I could report them in a helpful and reproducible way. Is there documentation somewhere? I’d enjoy reading a Jitsi Meet Debugging How To or watching a video of developers tracking down a bug in the JS Console while they talk aloud what they are thinking. Does anything like that exist, @damencho?

1 Like

Just to clarify (since I’m the author of the linked post), the crashes I was referring to were in Chrome 93 (which was so crashy with WebRTC that I assumed you must be using that version!). I haven’t seen any major issues in Chrome 94/95/96.

Just speaking generally for any browser-based product, it gets progressively more difficult to support a given older browser version, the more out-of-date that the browser version gets. This is especially problematic when the older browser version contains high-impact WebRTC bugs, because you have to maintain (and test) a lot of technical debt just to work around those bugs.

So you have a large amount of work needed to maintain support for obsolete versions, and then it can also be difficult to prioritise that work, because these days the vast majority of users are running the latest version thanks to rapid auto-updating by browsers on the major platforms. An issue impacting Chrome 90 is impacting 0.12% of users. An issue impacting Firefox 78 is impacting 0.14% of users. (Source.)

Honestly, it’s very hard to argue that limited developer time should be spent on adding or maintaining technical debt to work around bugs in these browser releases used by a combined 0.26% of users, versus spending that time on almost anything else.

One thing I would love to see is a formal browser support policy for Jitsi. (Maybe it exists and I haven’t come across it?) How long versions are supported for, whether the latest ESR is also supported, etc. This would give certainty and perhaps make it easier to prioritise developer resources.

1 Like

Curious - can you share those changes? I’m interested in knowing that changes exactly have been rolled out by Jitsi that broke these browsers (and still remain unfixed).

I feel like you’re not really getting how these things work. Working on backwards compatibility is a huge task on its own and the Jitsi team has repeatedly made clear that they favor the latest versions of these technologies. Sure, they look into issues when complaints are made about new releases not working with older browsers, but their commitment is clear - most recent versions are favored.

From what you’ve shared, it seems you’re choosing to stay on older versions of these clients and your complaints are really all centered around backwards compatibility. When I said most of these issues you’re referencing are browser-related, I meant it. For instance, Chrome has moved to Unified Plan and will completely cease to support Plan B in the next few weeks. The most recent versions of Jitsi have been developed to adapt to that change. So if you try to use an older Chrome browser on the latest Jitsi version, you will have problems (trust me, I tested this). To then conclude that Jitsi’s upgrade “broke Chromium” either shows a lack of understanding of how these things work, or suggests an attempt at an outrightly disingenuous assertion, at best.