100% support for Firefox (and other non-Chrome browsers)

[jans23]

I'm using Jitsi Meet (The public service hosted at https://meet.jit.si/) for two years now and in my experience it doesn't work reliably with Firefox. I even think as soon as one of the conference members uses Firefox, sooner or later the conference will experience some audio or video issues. Consequently we can't use Jitsi Meet well for a wider/external audience because we can't demand them to use Chrome.

The actual issues experienced range from voice and video drop outs, to connectivity issues (poor connectivity or connection lost). As soon as the Firefox members leaves, the issues stop appearing. Because these issues are so blur I can't provide any details at the moment. Therefore I have the general question, if you plan to support Firefox 100%? If I should provide more technical details about the issues, where can I find description how to gather those details?

[damencho]

Sorry for the late answer. The situation is that we haven't added simulcast support to Firefox and if you have several people with Firefox in a conference they will significantly increase traffic to every participant which can cause issues like CPU spikes, like a problem with filling up the available download bandwidth for user ...
We have and a known issue with Firefox which is not addressed, but the good news is that we will soon start working on better Firefox support, so stay tuned for the time being using chrome is the best option out there for the moment.

[MatthieuPERIN]

Several attempts to use internal Jitsi instance with Firefox 71.0 (64 bits) windows client have bring some issues :

• Lack of sound (work fine within Chrome) for my client
• No microphone detected (the other participant)

If needed, I can provide any dump/config needed.

Have a great day 👍 (and please bring 100% support for Firefox 😄 )

[damencho]

@jallamsetty1 Is currently working on it :) Cheers.

[Mte90]

Just saw this yesterday :-(

Looking on bugzilla there are 2 tickets like https://bugzilla.mozilla.org/show_bug.cgi?id=1600698 that need to fixed or also https://bugzilla.mozilla.org/show_bug.cgi?id=1468700

[mirh]

Also https://bugzilla.mozilla.org/show_bug.cgi?id=1210175 ?

[mestaritonttu]

Is this FF issue also still a blocker: https://bugzilla.mozilla.org/show_bug.cgi?id=1164187 ?

[mimi89999]

Hello,
Two days ago I tried Jitsi Meet with 3 other people. Three of us were using Firefox. During the meeting there were constantly issues with one participant not being able to hear another one. The meeting ended quickly and they said that they will never use Jitsi Meet again.

If this is an issue with Firefox, I think that Jitsi Meet should show a bigger warning (the small one is just clicked through without being read) or even completely block Firefox users. For people not wanting to use Chrome nor Chromium, an Electron app could be easily offered.

[aiomaster]

I agree this should be fixed, cause people think jitsi meet is buggy.
Just to be fair: There is an electron app: https://github.com/jitsi/jitsi-meet-electron
Last official release is from 2018, but it seems to be developed and it is working, at least for me.

[J0WI]

If this is an issue with Firefox, I think that Jitsi Meet should show a bigger warning (the small one is just clicked through without being read) or even completely block Firefox users.

Please do not block clients based on their user agent string. Clients should rather be tested for available features to provide the best experience for all.
Custom Add-ons, privacy settings, unstable branches or even network issues (IPv4/6, NAT) can all affect the behavior of a client and it's not possible to detect all of them. Even if some features are not supported it's still better if you're able to join with limitations than not at all.

[mcnesium]

I have been in several video conferences with >2 participants on different self-hosted Jitsi instances deployed using the Docker setup during the last week with my Firefox 74/Linux, so I can assure it does work with Firefox.

My experience shows that it did not work on setups where ports 4443 and 10000 were blocked on the server by a firewall. Maybe this helps…

[weiss]

Clients should rather be tested for available features

You cannot easily test for the feature in question.

[jallamsetty1]

We appreciate all the feedback ! Firefox has a very different implementation of the WebRTC SDP format than Chrome and we had decided to focus our efforts on keeping chrome up to date in the past. The WebRTC spec has evolved a lot in the last 1-2 years and all the browsers are merging towards WebRTC 1.0 which makes it easier for us.
We have made a lot of progress on getting our Firefox and Safari support up to speed lately and we are in the process of merging these changes. This is how these implementation changes manifest to the users

• Signaling issues will be gone, i.e., one of the participants not receiving audio/video.
• Better video quality since we are introducing simulcast support for FF.
• Better statistics as we are moving to the spec compliant stats.

I will update this issue once these changes make it to a Jitsi Meet release.

[jallamsetty1]

Is this FF issue also still a blocker: https://bugzilla.mozilla.org/show_bug.cgi?id=1164187 ?

Yes, this is still a blocker. FF hasn't implemented RTX support which means that the when we experience packet loss, we won't be able to retransmit these missing packets.

[cjhille]

If this is an issue with Firefox, I think that Jitsi Meet should [...] or even completely block Firefox users.

@mimi89999
If i'm not mistaken you can quite easily do that yourself by adding firefox to the list of UNSUPPORTED_BROWSERS in interface_config.js.
See:

jitsi-meet/interface_config.js

Line 182 in f5a0a1e

UNSUPPORTED_BROWSERS: [],

[nils-ohlmeier]

Yes, this is still a blocker. FF hasn't implemented RTX support which means that the when we experience packet loss, we won't be able to retransmit these missing packets.

Just to be factual correct: implementations can retransmit lost packets also without RTX. Otherwise calls with Firefox on other services would hang all the time, which they don't. Jitsi favors RTX for retransmissions, and as you can see in the Firefox bug integrating the feature into non-Chrome browsers is challenging.

[freechelmi]

My experience shows that it did not work on setups where ports 4443 and 10000 were blocked on the server by a firewall. Maybe this helps…

But This should be the case for any browser if there is no TURN server to route the traffic on some 443 port to jvb.

[emcho]

Yes, this is still a blocker. FF hasn't implemented RTX support which means that the when we experience packet loss, we won't be able to retransmit these missing packets.

Just to be factual correct: implementations can retransmit lost packets also without RTX. Otherwise calls with Firefox on other services would hang all the time, which they don't. Jitsi favors RTX for retransmissions, and as you can see in the Firefox bug integrating the feature into non-Chrome browsers is challenging.

Just to be factually correct. RTX is the IETF recommended way. If this was about pragmatical approaches, FF would be supporting Plan B SDP and this entire Jitsi/FF situation wouldn’t have been a thing!😉

[mordae]

Sometimes other clients lose incoming streams after a Firefox client rejoins the meeting. This might be the same issue as #5439.

Our latest test setup: 5 users (1x iOS client, 2x Firefox, 2x Chromium)
Tested on: a private instance, meet.jit.si/test-to, beta.meet.jit.si/test-to

Steps to reproduce:

1. Clients join the meeting.
2. One of the Firefox users presses F5.
3. After they reconnect, the other Firefox user presses F5.
4. The first Firefox user is affected and cannot see, hear or both some or all other clients. Videos just freeze.

Historically we have seen other variations of the issue, such as affected user not using Firefox.

Please advise on debugging this issue.

(We can try to reproduce the issue on your infrastructure, if you are willing to manage us. We are available approximately from 10:00 to 20:00 UTC. Drop me an SMS at +420723671732.)

[chagai95]

I used jitsi yesterday with a participant using Firefox - when she was not muted we could all hear each other twice, why did this happen? also, we were all muted several times automatically but that might be a general problem not sure that is connected to that participant with Firefox. We tried Zoom and that worked fine on said participants Computer

[awienecke]

Just tried recently, everything seems to work, but screen sharing is only visible from non-firefox clients.

Specifically: browser that is sharing doesn't matter; Browsers receiving, only non-firefox browsers can view the shared screen.

[daraul]

If it has not been done already, I think the best option is to put a note in the readme or wiki showing Firefox users where jitsi in terms of "100% support for Firefox". That way nobody gets notified when arguments like this come up, and those who want to get an "overview" of the state of things can refer to that note.

This issue can then be locked to maintainers.

[peternowee]

put a note in the readme or wiki showing Firefox users where jitsi in terms of "100% support for Firefox".

I don't know. Wiki and readme files can usually only be edited with permission, so tend to not get updated after a while anymore. A meta-issue (as long as it is not locked) is still open for user comments.

[saghul]

I think the best option is to put a note in the readme or wiki showing Firefox users where jitsi in terms of "100% support for Firefox"

I don't see how that would be useful, since we don't know what we don't know. So one can never know the state of Firefox for new and unreleased versions.

[abitrolly]

I hope that everybody is aware of the Unsubscribe button at the bottom of the right side menu for no hard feelings. It works per issue and doesn't affect all other notifications.

[riyazpanarwala]

Here speaker and microphone selection is disabled in firefox.

browser version :- 85.0 firefox
system : windows 10

[cpot]

This annoying issue exists already in FF 84.x

[Sciss]

Today was kicked out every few minutes, using FF 78.7 on Linux; hadn't happened in long time. Very annoying, switching to Chromium immediately "fixed" the problem. Having to rely on the Google monopoly is very bad. Thanks

[damencho]

@Sciss Was that on meet.jit.si? Have you tried updating Firefox?

[Sciss]

@damencho yes on meet.jit.si ; FF version is the one of Debian stable, so I prefer not to update. If the problem vanishes on newer FF, I'm willing to switch to Chromium until Debian 11 is stable.

[damencho]

I have no idea what was the problem, to be able to say. I'm just trying to understand more ... to find out what can be the problem. We did roll out an update last week where a reload happens if certain headers are missing or different from an xhr request ... I wonder can that be messing up on that Firefox version somehow ... was there anything specific in your roomname, if you can share it with me damencho at jitsi dot org. Thank you.

[Zesko]

I checked jitsi video using Firefox 89 (latest version) and Chromium (latest version) on Linux. I notice the difference of performance. Chromium is smoother than Firefox.

[Zesko]

I checked jitsi video using Firefox 89 (latest version) and Chromium (latest version) on Linux. I notice the difference of performance. Chromium is smoother than Firefox.

I found media.webrtc.hw.h264.enabled should be enabled in the setting about:config. Then video streaming is smooth like Chromium.

I do not understand, why is it disabled by default?

[rugk]

I have no idea, but I opened a ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1717679

[Zesko]

I have no idea, but I opened a ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1717679

Thank you.

Hangout (Google Meet) also uses webRTC like Jitsi, but Hangout does not need this setting media.webrtc.hw.h264.enabled and runs more smoothly than Jitsi in Firefox without freeze. Why?

[abitrolly]

H.264 is a patent restricted codec, so it may not be available by default on open source systems.

[rugk]

That is correct and it is downloaded from Cisco for some distros, but anyway, if it is available it can IMHO be used…

[abitrolly]

So that's not a Firefox support then, but H.264 support. The fix could allow Jitsi to report that no hardware acceleration is available and recommend to use some unencumbered acceleration like AV1. I don't know which free codecs are good for videoconferencing.

[jbg]

There's a lot of confusion in this issue, it seems.

• Jitsi Meet doesn't support AV1 yet. (It's very early days for WebRTC + AV1 in general.)
• Jitsi Meet normally uses VP8; recently it has gained VP9 support too. It does support H.264, but:
• Using H.264 for anything other than P2P is not ideal, because there's no simulcast support (neither in Jitsi Meet – issue – nor in Firefox – issue).
• In basic tests (especially with only 2 participants) you may find H.264 is an improvement, only to find that once you have more participants and anyone has a less than perfect connection, it's much worse, because you don't have simulcast.

[raoulbhatia]

Out of curiosity, night this be related to the recent comments?
https://bugzilla.mozilla.org/show_bug.cgi?id=1708224

Fixed in Firefox 89.0.2, see https://www.mozilla.org/en-US/firefox/89.0.2/releasenotes/

[jbg]

@raoulbhatia did you mean to link to another bug? 1708224 is a bug in WebRender and has nothing to do with WebRTC nor H.264 simulcast. This bug would have manifested itself as intermittent hangs when browsing the web.

[CyprienLe]

Hello,
I'm using firefox and when I try to share screen on jitsi nothing happen. Do you have an idea of how can I fix that?
Thank you

[mohicanb]

Hello,
I'm using firefox and when I try to share screen on jitsi nothing happen. Do you have an idea of how can I fix that?
Thank you
Hello @CyprienLe , for me it works.

Did you try a default profile on Firefox ? (This problem could come from extensions or custom settings in Firefox).
Other idea : could be a problem of authorization on your OS. Are you on MacOS ? (I've heard this kind of problem appears on Macs)

[abitrolly]

@CyprienLe may not be only Firefox. There was a problem with screen capture on Linux + Wayland, but now Jitsi works correctly with Firefox 89 on Fedora 34 + Wayland + GNOME.

[CyprienLe]

I have tried with my firefox account logged off, it still doesn't work. But it works with safari, so i think i will use safari for jitsi. Thank you

[james-see]

Streaming video via webrtc doesn't appear to work at all over Firefox. Any flags in about:config do not work either. I would just avoid Firefox completely. Brave, Chromium, and Edge all work fine out of the box if you don't want to go with a Google branded product like Chrome.

[ovari]

Streaming video via webrtc doesn't appear to work at all over Firefox. Any flags in about:config do not work either. I would just avoid Firefox completely. Brave, Chromium, and Edge all work fine out of the box if you don't want to go with a Google branded product like Chrome.

[meta] Update libwebrtc to new stable branch 2H2020 has been merged into the Firefox 96 branch. Can you test FIrefox 96 Nightly and and report any problems? Firefox 96 release is planned for 2022-01-11.

[MPeti1]

Streaming video via webrtc doesn't appear to work at all over Firefox. Any flags in about:config do not work either. I would just avoid Firefox completely. Brave, Chromium, and Edge all work fine out of the box if you don't want to go with a Google branded product like Chrome.

It works over here, though I'm not on latest FF.
Also, a few weeks earlier when I had the same problem it was somehow working on https://beta.meet.jit.si/, so you could try that out too.

[RalphCorderoy]

Hi @jamesacampbell, We could do with knowing what version of Firefox on what platform you were trying. Otherwise, it's a bit vague.

[saghul]

I think this issue has run its course already. Please discuss new Firefox problems by opening new issues.