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.

[richb-hanover]

I agree that highlighting in some form of documentation why recent versions of Chrome and Firefox have stopped working seems like a good idea.

Two thoughts:

1. I don't think many people will be interested in running their existing (old) server for very long. It will be too hard to support their users - FF80 will stop working first, then Chrome in the near future, etc. Each time it happens, the server admin needs to tell the caller to find a different browser, or download "that Electron thing..." Not fun.

2. Who could write such a note? (On the Forum would be great - it'll be timely, and can easily be updated.)

The article needs to describe the symptoms ("Firefox stopped working" - web browsers for people used to work but don't any more...), give a brief explanation (DTLS 1.0 no longer supported), and most importantly tell what people need to do to restore their server.

[bbaldino]

I thought I had made such an announcement (regarding DTLS 1.0) on the community at some point, but searching now I don't see one so I guess not. I don't know the details of the specific failure modes, but I can make a general post regarding the DTLS 1.0 deprecation and the requirement to move to jvb 2.

EDIT: Made a post here

[nils-ohlmeier]

FYI looks like we are going to delay removal of DTLS 1.0 once more https://bugzilla.mozilla.org/show_bug.cgi?id=1657808

[jallamsetty1]

In the Jitsi community call, we have been receiving reports of audio/video issues when using Firefox in large calls. As part of the client performance optimization work, we have been working on different features lately that are designed to bring down the client's cpu utilization. One such feature is called layer suspension that lets the client suspend sending HD simulcast streams when the bridge signals that it's no longer needed. We are able to do this on all browsers except Firefox because of a missing implementation there.
For those of you interested, here is the implementation bug report - https://bugzilla.mozilla.org/show_bug.cgi?id=1401592.

[rugk]

Commented there, because with the last activity being 5 months ago and the fact that the issue is not on their "jitsi-meet" whiteboard, this is something we need to make them aware.
Thanks for the link, @jallamsetty1 in any case.

[ovari]

Bug 1663368 Simulcast streams must be configured with highest resolution stream first
https://bugzilla.mozilla.org/show_bug.cgi?id=1663368

[rugk]

@ovari Thanks for the link. Yet again another issue that is not on their "jitsi-meet" whiteboard. So please make them aware of this, so they can priorize it.

[scroom]

Bug 1663368 Simulcast streams must be configured with highest resolution stream first
https://bugzilla.mozilla.org/show_bug.cgi?id=1663368

Bug seems to be resolved since Firefox 83

[nils-ohlmeier]

FYI this bug affected Firefox users with Jitsi (users reporting video freezes) https://bugzilla.mozilla.org/show_bug.cgi?id=1674463
It is resolved since Firefox 84, which is the current Release version.

[rugk]

So can we say Jitsi is now 100%ly supported by Firefox as this issue asks it?

(except for e2e encryption, of course)

[tremby]

Does this news relate to performance differences too?

[awlx]

I cannot confirm that Firefox is working now. Since 84 it seems broken again ... we have screenshare issues, connectivity issues and no video issues. Chrome and App works fine.

We run:
jitsi-meet-web 1.0.4576-2

[awlx]

We fixed the issue by removing the following stanza from the config:

 videoQuality: {
            maxBitratesVideo: {
            low: 200000,
            standard: 500000,
            high: 1500000
        },
    },

Edit:// ok it seems it didn't fix the issue for all users -.-

If you want to test https://meet.ffmuc.net

[rasos]

We have removed

startBitrate: "800",

for better results with simulcast on FF and inactive users shown #7227

[saghul]

Folks, please open new issues for new issues / regressions that happen with new Firefox releases. This issue is old and has too many comments already.

[abitrolly]

This thread is still convenient to be notified when Firefox 100% support breaks, especially with regressions.

[jonassmedegaard]

Quoting Anatoli Babenia (2021-01-12 11:47:50)

This thread is still convenient to be notified when Firefox 100% support breaks, especially with regressions.

No it isn't, because "100% support" is meaningless. Please close this bloated issue, and instead file individual issues. To get a feel for how close to "100% support" look at the amount of open issues.

[peternowee]

I agree with @abitrolly. As a user, I prefer to subscribe to just this one issue, as a kind of meta-issue for Firefox support, instead of having to search the issue tracker again and again for new individual issues. Good to open individual issues of course for contributors, but maybe just cross-mention them here in this meta-issue for users.

[saghul]

As a developer, I hate to go back to closed issues every time something new-though-tangentially-related happens.

Good to open individual issues of course for contributors, but maybe just cross-mention them here in this meta-issue for users.

This sounds like the perfect compromise!

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