Jitsi-meet: 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: https://github.com/jitsi/jitsi-meet/blob/f5a0a1ef8c50871deec77c7441115accd65e5fe2/interface_config.js#L182

[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 [phone].)

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

[chagai95]

Ok maybe she is using an older version of Firefox? Could that be the case?

[awienecke]

Firefox version 74 on my end, can't speak for the other end other than they should be the latest version available on windows.

[jallamsetty1]

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.

Thank you for reporting about this issue. We are aware of this and have a fix that will be merged soon.

[jallamsetty1]

Ok maybe she is using an older version of Firefox? Could that be the case?

Do you happen to know what kind of audio device this particular user was using ? There seems to be something wrong with echo cancellation on her machine.
When you say you were automatically muted several times during the call, did you mean you stopped receiving video/audio or you stopped sending audio/video. If it is the send side, will you be able to check with the participants if someone was doing "mute everyone else" ? I don't see how you all can be muted otherwise.

[jallamsetty1]

Using Firefox 74.0, 64 bits, windows10.
I must say using https://meet.jit.si with Firefox was OK except not working in p2p, and no information displayed into the session info, cpu 98%, gpu 50%, ethernet 5.5 Mbps

If testing on a latest version like https://vidconf.tech4good.ch, or https://www.free-solutions.org no audio or image at all...

Thank you for the feedback. We are aware of the p2p and stats issue and we are working on fixing those.

[chagai95]

Ok maybe she is using an older version of Firefox? Could that be the case?

Do you happen to know what kind of audio device this particular user was using ? There seems to be something wrong with echo cancellation on her machine.
When you say you were automatically muted several times during the call, did you mean you stopped receiving video/audio or you stopped sending audio/video. If it is the send side, will you be able to check with the participants if someone was doing "mute everyone else" ? I don't see how you all can be muted otherwise.

I don't, I'll try checking and getting back to you. I also thought so at the beginning but like I mentioned the same device worked fine with zoom's desktop application...

What I meant with "muted" is literally the mute button on jisti was set to mute and we had to all unmute ourselves manually before we talk, a few times...(I doubt somebody clicked on mute all because we were only 5 participants and ALL of us were muted when you click on mute all you personally stay unmuted and this wasn't the case here.)

[samtygier]

Bug 1600698 JITSI bandwith usage and status info partially fixed upstream. Support added, but needs media.navigator.video.use_transport_cc setting to true to use.

[nils-ohlmeier]

Bug 1600698 JITSI bandwith usage and status info partially fixed upstream. Support added, but needs media.navigator.video.use_transport_cc setting to true to use.

Our current plan is to not enable transport-cc by itself without RTX as we are concerned that this would be a feature combination which nobody has ever tested. Therefore our plan is to wait for RTX to become available in Firefox Nightly and then turn both feature on together.

[rmueller83]

Here is a list of all jitsti-meet tagged bugs for Firefox: https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=jitsi-meet

[EdaNano]

Hi,
I am really looking forward for this issue to be resolved in Firefox. Thank you for not forgetting and working on this <3
Just a question, which is important I think for people who care about data-friendly and libre tools (which Chrome is not) : is Chrome the only browser that is fully supported by Jitsi? Is for example Chromium (the open source browser from which Chrome is built upon, and some other browsers also like Edge, Opera, ...), differently supported from Chrome? Because if this is not the case, is it necessary to keep talking about Chrome by default?

Thank you for your work again.

[jonassmedegaard]

is Chrome the only browser that is fully supported by Jitsi? Is for example Chromium (the open source browser from which Chrome is built upon, and some other browsers also like Edge, Opera, ...), differently supported from Chrome?

The Free licensed Chromium is the basis (i.e. a subset) of non-free Chrome - signalling parts of WebRTC is same, but Chrome includes additional audio/video codecs that _maybe_ is used in WebRTC, and _possibly_ if you subscribe to Google account then you are more likely to avoid problems when behind a masqueraded (a.k.a. NAT) network due to access to Google TURN services.
Here's a random comparison: https://fossbytes.com/difference-google-chrome-vs-chromium-browser/

Instead of interpreting this issue as Jitsi being biased towards a non-free browser, I find it is more fair to describe the situation as jitsi having done WebRTC since very early, when Chrome/Chromium were the only reliable client implementation. Some of the design choices in Chrome/Chromium has caused headaches and has only very recently been reimplemented to align with those of Firefox - see e.g. https://www.callstats.io/blog/what-is-unified-plan-and-how-will-it-affect-your-webrtc-development

[tuxayo]

@jonassmedegaard

parts of WebRTC is same, but Chromium include additional audio/video codecs that maybe is used in WebRTC

You mean «Chrome include additional audio/video codecs» right?

That hopefully isn't a problem. For example, I see that on Arch Linux, there is a dependency on ffmpeg, same for Debian and Ubuntu. So we should be okay about codec support. However I don't know if the software implementation of these codecs is significantly faster in the Chrome one's. Same about hardware acceleration support.

[saghul]

Just a question, which is important I think for people who care about data-friendly and libre tools (which Chrome is not) : is Chrome the only browser that is fully supported by Jitsi? Is for example Chromium (the open source browser from which Chrome is built upon, and some other browsers also like Edge, Opera, ...), differently supported from Chrome? Because if this is not the case, is it necessary to keep talking about Chrome by default?

Any browsser using the Chromium engine should Just Work (TM). We mention Chrome because... it's shorter to type I guess? :-)

[EdaNano]

We mention Chrome because... it's shorter to type I guess? :-)

Oh I see ^^, how did I not think about that ;-) But ... Edge is even shorter...
And you know what else is even shorter? Tor ;) Not based on the same engine though, but based on Firefox. And to get back to Firefox, that's not shorter for sure ... but hey it begins with an "F" as in Free software, that's another niiiiiice reason to keep working on this issue ;-)

[tuxayo]

Instead of "Jitsi is biased towards a non-free browser" it is more fair to describe the situation as "jitsi began doing WebRTC very early, when Chrome/Chromium were the only reliable client implementation".

Thanks for the clarification.

Actually, Chromium is also recommended:
https://web-cdn.jitsi.net/meetjitsi_3962.622/static/recommendedBrowsers.html

It looks like you're using a browser we don't fully support.

Maybe the phrasing puts too much burden on Jitsi Meet's side.
As we see it seems that this is also a lot of work on the side of Firefox to do for apps like Jitsi Meet to work correctly.

One of the factor we have to be conscious is that the huge difference of means between Chrome and Firefox. And that the fact that Google has web conferencing apps since years (Google Hangout and Google Meet) which means they obviously focuses enough resources to make it work great.
And also they can abuse their power due to market share to do things in the way that is the most convenient for them.
And if they lead the work on a given web standard, they will have the advantage that the final spec will be very close to their own implementation on which they started to work on it much earlier.

[tuxayo]

As users, I think one of the things we can do it fund Firefox well. And also Jitsi Meet because it's one of our best tools out there for libre video calling.

An analysis (I Am Not An Accountant) of Mozilla's budget report[1] shows that 90% of Mozilla's income is from contracts with search engines. And only 0.74% of funding is from individuals. That's a 120/1 difference.

[1] french resource with some English citations from the report: https://colibris-wiki.org/revlibre/?PayeTonLL I can translate it if there is interest.

Does anyone from the Jitsi team can point to the issue that would help the most Firefox users currently?
So we could create a bounty and thrown some bucks at it. (this one is too generic for a bounty)

On the Firefox side, is the one about RTX for WebRTC a good one?

[Lennie]

@tuxayo this also exists: https://www.bountysource.com/issues/90834026-implement-rtx-for-webrtc
Maybe some people who want this but can't help directly can donate to this ?
(I got the link from the bugzilla entry)

[tuxayo]

@tuxayo this also exists: https://www.bountysource.com/issues/90834026-implement-rtx-for-webrtc

That is indeed the one linked in the previous message.

[tuxayo]

For further clarification @jonassmedegaard

Instead of "Jitsi is biased towards a non-free browser"

That's not an actual citation right? That's a translation of the perceived frustration on this thread about Firefox & Jitsi Meet not working well together right?

Frustration against Jitsi Meet which I had until I found out that they also recommend Chromium in their warning.

edit: original message was rephrased, no need to worry

[mordae]

I would like to add that my report is not related to the TCC/RTX issue. We were having issue even without video and everyone was comfortably way below their line capacities. Still, Firefox user entering the session somehow messed up someone else's connection.

Also, we have tested https://v3demo.mediasoup.org/ and the issue was not present.

If you need more data, let me know. I can arrange a manual testing session if you tell us what you need.

[XANi]

Meanwhile could the warning for firefox be worded more strongly? Vague "it might not work perfectly" does not really convey the impact of the issue, considering that FF users can make it bad for everyone.

[awlx]

We (@FreifunkMUC) for now added the Browser to UNSUPPORTED_BROWSERS list and adjusted the warning to also refer the Apps ...

https://twitter.com/FreifunkMUC/status/1247103136856145920

[EdaNano]

We (@freifunkMUC) for now added the Browser to UNSUPPORTED_BROWSERS list and adjusted the warning to also refer the Apps ...

https://twitter.com/FreifunkMUC/status/1247103136856145920

Hi, isn't this a little bit strong? I am actually using Jitsi from different instances/servers on Firefox with classes of more then 30 students, I am not having problems due to Firefox that I can name that they are due to Firefox. Maybe on Chromium based browsers (not only Chrome by the way, because you only mention Chrome) things would have been better, but clearly her I am able to use it on Firefox with 30 students. That's not nothing.

[awlx]

Hi, isn't this a little bit strong? I am actually using Jitsi from different instances/servers on Firefox with classes of more then 30 students, I am not having problems due to Firefox that I can name that they are due to Firefox. Maybe on Chromium based browsers (not only Chrome by the way, because you only mention Chrome) things would have been better, but clearly her I am able to use it on Firefox with 30 students. That's not nothing.

We have too many complaints and always Firefox was the issue :/. And as we are all volunteers we cannot keep up with the support requests so this decision was made until Firefox works stable with Jitsi. So yes, we don't like this solution but at the moment we see no other way to keep 600 - 700 concurrent users happy.

But we also added a bit more explanation :).
https://ffmuc.net/wiki/doku.php?id=knb:meet-downloads
https://ffmuc.net/wiki/doku.php?id=knb:meet-en

And for now users seem to accept the change:
https://stats.ffmuc.net/d/U6sKqPuZz/meet-stats?orgId=1&refresh=1m

[EdaNano]

We have too many complaints and always Firefox was the issue :/. And as we are all volunteers we cannot keep up with the support requests so this decision was made until Firefox works stable with Jitsi. So yes, we don't like this solution but at the moment we see no other way to keep 600 - 700 concurrent users happy.

Oh I see, I understand.

But we also added a bit more explanation :).
https://ffmuc.net/wiki/doku.php?id=knb:meet-downloads
https://ffmuc.net/wiki/doku.php?id=knb:meet-en

Jes, I see :) By the way the Jitsi Meet app is also available from F-Droid : the FOSS alternative store to Google Play Store that you mention on the wiki :) Without F-Droid, no free andoid telephone would be possible, a little bit like the wifi world would be without Freifunk :) <3

[rasos]

I've heard in today's Jitsi community call, that the team is working hard to improve the Firefox compatibility with an ETA of 1-3 weeks.

Meanwhile, we've made the page with recommended browsers look a bit nicer for our community. Feel free to copy/adapt: https://fairmeeting.net/static/recommendedBrowsers.html

[tuxayo]

Good to know Jitsi Meet can still improve things on their side :D

Is/are there a specific/s ticket/s to follow?

[steve-clickacall]

I was in yesterday's community call (thank you for organising this guys!!). As @rasos says above it was mentioned in the call that firefox "and safari" will be improved in 1-3 weeks. But for those of us not as technical as the amazing jitsi dev team and who haven't followed the history for very long, can somebody please explain what the changes will be and what improvements users will see? and when it says Safari, I presume this means on iOS mobile devices so that we can now deliver jitsi Meet onto mobile browsers?

[PeterTheOne]

Community Call https://youtu.be/feksoqPCAhI?t=2951

[pdarcos]

Hi guys,
How about Brave browser?
I use it all the time and haven't noticed any issues at all (except that the first time you go to jitsi meet server you have to allow auto-play on that page).

And it's also FOSS and very privacy friendly.
Shouldn't we add it to the supported - and maybe even recommended - supported browsers?

[johanricher]

FYI Brave is based on Chromium.

[Pascal-KOTTE]

And it's also FOSS and very privacy friendly.
Shouldn't we add it to the supported - and maybe even recommended - supported browsers?

https://en.wikipedia.org/wiki/Chromium_(web_browser)#Browsers_based_on_Chromium
And about near 100% base browser any Androïd

Well the new EDGE also very well supported! https://www.microsoft.com/fr-fr/edge/
oops...

[steve-clickacall]

thanks for the youtube clip Peter. But from a user perspective, what can they expect to see differently? and is there anything that will still not work well on firefox/safari?

[jallamsetty1]

thanks for the youtube clip Peter. But from a user perspective, what can they expect to see differently? and is there anything that will still not work well on firefox/safari?

Improvements to signaling

• Better handling of how remote sources are added and removed on the client. All the issues where audio/video is not received when a Firefox/Safari participant joins the call should be fixed.

Improvements to bandwidth estimation and adaptation

• By adding simulcast support to Firefox and Safari, we are now able to adapt to the changing network conditions on the downlink. The bridge will be able to send 180/360/720 stream based on the available downlink as opposed to sending 720p always.
• Enhancements to our bandwidth probing mechanisms for both Safari and Firefox resulting in more accurate bandwidth estimates.

New Features

• Desktop sharing support added on Safari.

Statistics

• Fixed transport stats for Firefox and Safari.

[eliot-akira]

Thank you for the update, @jallamsetty1 - I'm sure many in the community will welcome these improvements to support non-Chrome browsers. If there will be a blog post (even a short one), we'll be happy to promote it.

[steve-clickacall]

Thank you @jallamsetty1 this sounds like some amazing work that will help the entire community. We are still deciding whether to switch our product from tokbox to jitsi. I am 100% sure it is a good move, but my non-tech business partner is unsure because of non-support for these browsers. So can you just confirm, in a non-tech way, that safari and firefox will now be “fully working”? And for safari, does this include all mac, iphone and ipad devices?

[chagai95]

for safari, does this include all mac, iphone and ipad devices?

I'm pretty sure it does - there is an iPhone app which is more stable and has priority if I understood correctly and the safari iPad and Mac is the same safari I was told. I assume safari on iPhone will not be supported for a while but safari for desktop (which is the one on iPad too) will hopefully work in the next few weeks.

[kr4ut]

@jallamsetty1 Wonderful news :heart_decoration: Can we assume it will obsolete the resolution option? We're currently using that countries/groups with low bandwidth. Any plan when your awesome work will hit Debian stable packages?

[DBJRdev]

@kr4ut : Don't know whether it helps, but at least it's easy to check visually for new package releases via browser: https://download.jitsi.org/stable/
In the community call they said probably within the next 1-2 weeks (counted from today)

[freechelmi]

AFAIK , Safari does not have any capture audio support yet.

[steve-clickacall]

@chagai95 - oh, so jitsi meet will still not work on iPhone safari browser? ;-(

[chagai95]

@chagai95 - oh, so jitsi meet will still not work on iPhone safari browser? ;-(

I have no idea, I believe it won't - let's see in two weeks :) I would also try clicking on desktop mode maybe that'll do the trick and I think it doesn't work on Chrome on iPhone either...

[kr4ut]

@DBJRdev Thanks for telling the road map just looking at packages releases doesn't help :wink:
@jallamsetty1 Beside all the doesn't work for me locally reports here we just reconfirmed a simple test case between two Firefox 75.0 (Ubuntu 18.04 build) via v2.0.4384-1 and comparing desktop bandwidth with nload. Iterating resolution at server config with 720/480/360/180 doesn't make any difference. Neither does changing video quality client wise in Firefox. Bandwidth starts shortly around ~0,8Mbit and goes directly to constant ~3Mbit. Only low bandwidth and disabling video brings it down to ~80Kbit.

[freechelmi]

@chagai95 - oh, so jitsi meet will still not work on iPhone safari browser? ;-(

I have no idea, I believe it won't - let's see in two weeks :) I would also try clicking on desktop mode maybe that'll do the trick and I think it doesn't work on Chrome on iPhone either...

You'll have to disable deep linking in config.js first.

[chagai95]

@chagai95 - oh, so jitsi meet will still not work on iPhone safari browser? ;-(

I have no idea, I believe it won't - let's see in two weeks :) I would also try clicking on desktop mode maybe that'll do the trick and I think it doesn't work on Chrome on iPhone either...

You'll have to disable deep linking in config.js first.

On Chrome clicking on desktop mode is sometimes enough otherwise you could open from incognito with desktop mode active and that always worked for me - maybe it's the same on safari?

[FlorianLudwig]

Hey all,

I get a lot of notifications here for ... something that is now a chat and not updates to the actual issue.

I believe there are more of people like me - subscribed here to this issue because it is an important one for them. Please keep this in mind when posting here! And move (general) discussions some place more appropriate.

Please? Thanks :heart:

[steve-clickacall]

apologies @FlorianLudwig some of us are new so not sure of the rules.

@everyone lets go to https://community.jitsi.org/t/browser-support-warning-when-using-the-latest-firefox-71-0-version-on-meet-jit-si/21180 to continue this discussion about improvements to firefox/safari support away from here (which is best left for the amazing dev team to do the actual changes ;-)

See you all at https://community.jitsi.org/t/browser-support-warning-when-using-the-latest-firefox-71-0-version-on-meet-jit-si/21180 so we can continue discussing this at a "user level" ;-)

[keithwbacon]

I was going to post about being unable to use Safari 13.1 on OS X 10.15.4 but I noticed if I change the user agent to Google Chrome MacOS it worked "good enough" for my purposes. I'm using the current stable release of Jitsi-meet. 2.0.4384-1. Thanks!

[mohicanb]

Hello, are the other Blink-based browsers like Brave https://brave.com/ and Falkon https://www.falkon.org/ 100% compatible with Jitsi Meet ?
If so please add them to the recommanded browsers list.

[ulab]

Brave is Chromium based and works here. No warning or anything, so I don't think it needs to be added to the recommended browsers list? Just as the 20+ other browsers based on Chromium either. Otherwise the list is going to get really long.

Falcon is based on the QtWebEngine. I am not sure if it will work and can't test it.

[chagai95]

Brave is Chromium based and works here

Is Brave on Android also Chromium-based? I couldn't find an answer online...thanks for your answer!

[ulab]

Is Brave on Android also Chromium-based? I couldn't find an answer online...thanks for your answer!

It is, but Jitsi still tells you to use the app.

[astrojuanlu]

Hey all,

I get a lot of notifications here for ... something that is now a chat and not updates to the actual issue.

I believe there are more of people like me - subscribed here to this issue because it is an important one for them. Please keep this in mind when posting here! And move (general) discussions some place more appropriate.

Please? Thanks ❤️

[abitrolly]

Firefox RTX for WebRTC is getting some commits - https://bugzilla.mozilla.org/show_bug.cgi?id=1164187#c53 )

[HelloWorldUser123]

Hi, just for clarification - the fixes for Firefox and Safari, are these related to Jitsi or directly to Firefox. My question, do I have to update Firefox or are older versions i.e. Firefox ESR 68 also supported? Thanks

[jens1o]

@HelloWorldUser123 The fixes included in Firefox will not be backported to the 68 ESR version. The next ESR version is scheduled to release in end June/early July.

Proof (while actually it is from me): https://twitter.com/firefox/status/1246398994928087048

[HelloWorldUser123]

Thanks for the answer. But regarding this issue says 100% support for non-Chrome browsers means for me also safari. Are there also changes coming directly to Jitsi to better support Firefox and Safari at all? We are currently seeing with multiple attendees of firefox a lot of errors "addRemoteStream" where the picture freezes and so on.

[jallamsetty1]

Thanks for the answer. But regarding this issue says 100% support for non-Chrome browsers means for me also safari. Are there also changes coming directly to Jitsi to better support Firefox and Safari at all? We are currently seeing with multiple attendees of firefox a lot of errors "addRemoteStream" where the picture freezes and so on.

Hey there, yes the changes to Jitsi will include fixes for Safari as well. Do you have the latest lib-jitsi-meet or jitsi-meet (depending on your implementation) ? We had a meet.jit.si release last weekend which should include fixes for addRemoteStream issues. If you still see errors, can you please send me the logs ? Thanks !

[steve-clickacall]

But will this include Safari on iOS?

[jallamsetty1]

But will this include Safari on iOS?

We are working on fixing video rendering issue on Safari on iOS. Currently, media is sent and received by the client but only the first frame is rendered.

[HelloWorldUser123]

Hey, thanks for the fast answer. Actually we are still on the version before the weekend. That are great news. Tomorrow we will try it with the new version - I will update you if the issues are again.

But will this include Safari on iOS?

We are working on fixing video rendering issue on Safari on iOS. Currently, media is sent and received by the client but only the first frame is rendered.

We experienced this issue in iOS safari for video elements which doesn't have the playsinline attribute in place. I don't think that the problem is that only the first frame is rendered. I think the problem is that iOS safari doesn't autoplay it. Please try to add the "playsinline" attribute to the video tag.
https://developer.apple.com/documentation/webkit/safari_tools_and_features/delivering_video_content_for_safari

[jallamsetty1]

Hey, thanks for the fast answer. Actually we are still on the version before the weekend. That are great news. Tomorrow we will try it with the new version - I will update you if the issues are again.

But will this include Safari on iOS?

We are working on fixing video rendering issue on Safari on iOS. Currently, media is sent and received by the client but only the first frame is rendered.

We experienced this issue in iOS safari for video elements which doesn't have the playsinline attribute in place. I don't think that the problem is that only the first frame is rendered. I think the problem is that iOS safari doesn't autoplay it. Please try to add the "playsinline" attribute to the video tag.
https://developer.apple.com/documentation/webkit/safari_tools_and_features/delivering_video_content_for_safari

This is very helpful, will give it a try, thanks !

[steve-clickacall]

@jallamsetty1 and @HelloWorldUser123 thank you for the update. We have had similar issues with Safari on iOS. Mobile browsers is key for us, so please let us know if you need help with some extra testing...

[cpot]

Perhaps a specific issue for Safari will make sense (Chromium should not be an issue, it works well with Edge-Chromium and Opera as far as we know)

This issue is too broad unless everything can be solve at the same time (is it realistic?)

Thank for all team working hard to make Firefox (and next ESR) working with jitsi, we see a big demand

[HelloWorldUser123]

But will this include Safari on iOS?

We are working on fixing video rendering issue on Safari on iOS. Currently, media is sent and received by the client but only the first frame is rendered.

We tested it with iOS safari and your change yesterday, thanks for that. Video is working as viewer. But now iOS has some problems when someone joins or someone (also myself) switch the camera - it runs into an error and reloads.
edit: only if there are two or more people in the room

[Dan33l]

For placing the church in the center of village, the jitsi sdp-interop gives corrects details of troubles with Chrome-like browsers and all the rest of the world.

[bhack]

@Dan33l In what transition phase we are now with current stable chrome and derivatives? https://webrtc.org/getting-started/unified-plan-transition-guide

[bhack]

The most updated info is that I find is at https://bugs.chromium.org/p/chromium/issues/detail?id=857004

[pdarcos]

Just updated my installation to latest unstable and tried using Firefox (75.0 64bits) on ubuntu.

It seems to work mostly well except I noticed that
1) P2P and bandwidth stats are still buggy/empty
2) Firefox doesn't offer me any options for choosing speakers, just camera and microphone. The speakers drop down is empty, but I know it can see my USB headset since the microphone shows up on the dropdown list as expected.
3) Tried using the exact same setup with Chrome and there the headset speaker is present and the P2P/bandwidth stats work fine.

Hope this helps.
Thanks for the great work. Can't wait to have full Firefox support working well with Jitsi-Meet!

[jallamsetty1]

Thanks for testing out the latest unstable, it is appreciated! We are in the process of making a release this week with all these changes. Let's not spam this thread with browser specific issues, please start a new thread once the release is out.
From Jitsi side of things, all the work for getting the signaling and media to work correctly on non-chromium browsers is done.
The issues that have been reported above with device detection and stats are browser limitations/bugs. For example, Firefox and Safari don't let us set the sink for audio, i.e., change the audio output, it has to be done through the system settings only. There are more of these browser specific limitations, I will be happy to give links to the corresponding browser bugs in the browser specific thread.
The only exception is P2P, we have disabled it for non-chromium based browsers because we are running into BWE issues, we will turn it back on once those issues are sorted out.

[saghul]

I'm closing this since we have the first step in place. Please open new issuess speccific to a given browser, should you find any.

[bhack]

@saghub Let us know if you have a list of upstream bugs in Firefox's bugzilla the we can upvote.

[leonardehrenfried]

As posted upthread, here is a list of bugs with the tag jitsi-meet: https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=substring&status_whiteboard=jitsi-meet

I can't say how relevant these bugs really are. At least on of them is actively worked on.

[cpot]

This Firefox compatibility is a huge improvement for Jitsi, thank you a lot.

When the .deb release will be ready? (we hope very fast)

[damencho]

This is already available in latest debian packages in unstable repo.

[bhack]

You can also use the last Firefox stable from https://flathub.org/apps/details/org.mozilla.firefox

[cpot]

This is already available in latest debian packages in unstable repo.

Thank you very much.

• How it is possible to know which version we are using on https://meet.jit.si/ i can't find a way to know the build number
• Do you have a expected date for stable repo ?

Again thank you

[damencho]

• Do you have a expected date for stable repo ?

And we just pushed a stable with the latest changes.

• How it is possible to know which version we are using on https://meet.jit.si/ i can't find a way to know the build number

That is a tricky one :) So we normally try to push a version that matches the jitsi-meet version (the meta packages), but it is not always possible, like today :) Stable jitsi-meet now is 2.0.4468.

So to check the versions on meet.jit.si, open the HTML sources and you will see:
base href="https://web-cdn.jitsi.net/meetjitsi_4025.677/
From here you can get the web version 4025 is what is now in stable.
Then open two tabs and open Developer Console and filter by version and you will see jicofo and jvb version:

[tpo]

@damencho I'd be glad if you could clarify: which of the following statements is true?

• the latest stable Jitsi Meet release (as released as Debian packages) contains improvements that make it work just fine with current Firefox ESR
• the current nightly build of Firefox works just fine with the latest Jitsi Meet release

From reading the comments above I can not figure out which one of these statements is true.
By "working just fine" I mean "does not disrupt the experience for all other participants due to missing RTX implementation".

?

Thanks a lot!

[damencho]

• the latest stable Jitsi Meet release (as released as Debian packages) contains improvements that make it work just fine with current Firefox ESR

Nope, we just disabled simulcast for ESR. I think the next ESR coming in two months will be fine.

• the current nightly build of Firefox works just fine with the latest Jitsi Meet release

Yes.

[fluboi]

Does anyone understand Mozilla's bug tracker?
I don't understand from which specific Firefox version we can expect better behavior (simulcast and RTX support). (running latest stable jitsi-meet on server side)

Is the current last stable release (75.0) supposed to work well thanks to jitsi side improvements ?

[mestaritonttu]

Does anyone understand Mozilla's bug tracker?
I don't understand from which specific Firefox version we can expect better behavior (simulcast and RTX support). (running latest stable jitsi-meet on server side)

Is the current last stable release (75.0) supposed to work well thanks to jitsi side improvements ?

Let's look at bug 1606823 , for example. In its comment 26 we can see the fields that were changed at the same time:

Status: ASSIGNED → RESOLVED
Closed: 18 days ago
status-firefox76: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla76

status-firefox76 tells us that this change will be in Firefox 76.

If you see some report that does not have status FIXED, then it probably is not fixed properly yet and you have to be patient.

[ovari]

Enable by default setSinkId pref
https://bugzilla.mozilla.org/show_bug.cgi?id=1498512

Please add support in Firefox for changing of the audio output devices
https://bugzilla.mozilla.org/show_bug.cgi?id=1631672

Hey there, what browser are you seeing this on ? Please note that the speakers will only be enumerated one chrome. Firefox and Safari, do not support changing of the audio output devices and therefore do not enumerate those devices.
https://github.com/jitsi/jitsi-meet/issues/6208#issuecomment-616929454

[jwflory]

Thank you Jitsi team for adding Firefox support! :heart: Looking forward to FF 76. :smile:

[richb-hanover]

Yes, it appears that FF 76 will work much better. Using earlier versions (on Jitsi from early April), two FF 75 sessions would freeze when connecting through my slow DSL (7mbps down/768kbps up) ISP link.

I just updated my report on the Community server to show that I could get at least two FF 76 connections working on that bandwidth-limited connection.

[ovari]

Mozilla's Positions on Emerging Web Specifications
https://github.com/mozilla/standards-positions/issues/330

support webrtc insertable streams
https://bugzilla.mozilla.org/show_bug.cgi?id=1631263

Insertable streams support in Firefox issue to give access to:

• end-to-end encryption
• adding more reliability with forward error correction

For more information, please watch the “Jitsi Community Call” (Streamed live on 21 Apr 2020) at 21’30”
https://youtu.be/y4CW3c_Es4I?t=1290

It is understood that Chromium has the insertable streams feature.

Thank you

[klint]

Here is the view on Firefox bugs&FR related to jitsi, with indication of priority and status for the 4 current FF versions (75 release, 76 beta, 77 nightly and 68ESR) :https://bugzilla.mozilla.org/buglist.cgi?columnlist=bug_type%2Cshort_desc%2Cproduct%2Ccomponent%2Cpriority%2Cassigned_to%2Ccf_status_firefox75%2Ccf_status_firefox76%2Ccf_status_firefox77%2Ccf_status_firefox_esr68%2Cbug_status%2Cresolution%2Cchangeddate&query_format=advanced&status_whiteboard=jitsi-meet&status_whiteboard_type=substring&query_based_on=
To be used with care, but it gives some indication on the progress.

[klint]

Here is the updated above view following the FF76 release (quite easy to update, just change the versions in the string ;) ): https://bugzilla.mozilla.org/buglist.cgi?columnlist=bug_type%2Cshort_desc%2Cproduct%2Ccomponent%2Cpriority%2Cassigned_to%2Ccf_status_firefox76%2Ccf_status_firefox77%2Ccf_status_firefox78%2Ccf_status_firefox_esr68%2Cbug_status%2Cresolution%2Cchangeddate&list_id=15209821&query_format=advanced&status_whiteboard=jitsi-meet&status_whiteboard_type=substring&query_based_on=

[richb-hanover]

Here is the updated above view...

I have a bit of trouble following the discussion at Bugzilla/Mozilla Standards Positions

Would you summarize what you think is going to happen? Thanks.

[nils-ohlmeier]

I have a bit of trouble following the discussion at Bugzilla/Mozilla Standards Positions

Would you summarize what you think is going to happen? Thanks.

Mozilla will comment in the issue once we internally have come to a conclusion.

[ovari]

Dan Minor [:dminor] from comment #89)
We've turned it [RTX for WebRTC] on by default in Firefox 80.

• Firefox release date 2020-08-25
• Firefox 80 Release Notes

[ovari]

Is there 100% support with Jitsi Meet Electron (Desktop application for Jitsi Meet built with Electron)? Is it better than using a web browser?

[jbg]

Is there 100% support with Jitsi Meet Electron (Desktop application for Jitsi Meet built with Electron)? Is it better than using a web browser?

Electron _is_ a web browser (slightly-out-of-date Chromium).

[Razzeee]

It's like using Chrome, as electron is based on that.

On Sat, Aug 1, 2020, 08:45 ovari [e-mail] wrote:

Is there 100% support with Jitsi Meet Electron
https://github.com/jitsi/jitsi-meet-electron#jitsi-meet-electron
(Desktop application for Jitsi Meet https://github.com/jitsi/jitsi-meet
built with Electron https://electronjs.org/)? Is it better than using a
web browser?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jitsi/jitsi-meet/issues/4758#issuecomment-667483452,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABNLEZAR3C4CAELNBLXHTFLR6O2XFANCNFSM4JBNR22Q
.

[richb-hanover]

Dan Minor [:dminor] from comment #89)
We've turned it [RTX for WebRTC] on by default in Firefox 80.

* Firefox release date [2020-08-25](https://wiki.mozilla.org/Release_Management/Calendar)

* [Firefox 80 Release Notes](https://www.mozilla.org/en-US/firefox/80.0/releasenotes/)

This looks promising. But the FF release notes also look as if FF80 turns off DTLS 1.0.

Is this going to cause problems with people running older versions of Jitsi? How will people with those installations know that it's essential they upgrade? (Or is this a non-issue?)

[saghul]

The JVB has supported DTLS 1.2 for quite a while now, so it shouldn't be an issue unless you're running a really old version of it.

[richb-hanover]

The JVB has supported DTLS 1.2 for quite a while now, so it shouldn't be an issue unless you're running a really old version of it.

Maybe I'm catastrophizing (worrying about a problem that won't exist...) But what will happen in this situation:

• Ancient version of Jitsi that has been running just fine
• All people using it are happy (including those with FF-pre version 80 which still uses DTLS 1.0)
• FF80 gets pushed out...

What will people see? What error messages, etc? What behavior will the (now-version 80) FF users see? How will the Jitsi site owner know what to do?

Note: I'm not suggesting to hold off with any updates, or try to fix those ancient versions of Jitsi. I'm just wondering what, if any, documentation/topics on the forum/issues here in Github we should provide to help the people who fall into the situation.

[jbg]

The JVB has supported DTLS 1.2 for quite a while now, so it shouldn't be an issue unless you're running a really old version of it.

Isn't JVB2 the first release that supports DTLS 1.2?

[jbg]

Maybe I'm catastrophizing (worrying about a problem that won't exist...) But what will happen in this situation:

* Ancient version of Jitsi that has been running just fine

* All people using it are happy (including those with FF-pre version 80 which still uses DTLS 1.0)

* FF80 gets pushed out...

What will people see? What error messages, etc? What behavior will the (now-version 80) FF users see? How will the Jitsi site owner know what to do?

As far as I'm aware, it will stop working unless the Jitsi installation is using at least JVB2. JVB1 uses ancient (~ a decade old) crypto libraries -- lack of DTLS 1.2 support is probably the least of the issues with them -- and will likely never get DTLS 1.2 support.

[jonassmedegaard]

Quoting Rich Brown (2020-08-01 20:30:32)

The JVB has supported DTLS 1.2 for quite a while now, so it shouldn't be an issue unless you're running a really old version of it.

Maybe I'm catastrophizing (worrying about a problem that won't exist...) But what will happen in this situation:

• Ancient version of Jitsi that has been running just fine
• All people using it are happy (including those with FF-pre version 80 which still uses DTLS 1.0)
• FF80 gets pushed out...

Those who wish to not upgrade software and are happy with that, should continue to not upgrade software and be happy with that.

I. e. they should continue to use also older browsers.

No, I am not at all recommending such approach: Those not upgrading their software are strongly advices to not expose their systems to the public internet - which severely reduces the usefulness of a Jitsi instance.

--

• Jonas Smedegaard - idealist & Internet-arkitekt
• Tlf.: [phone] Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

[richb-hanover]

Those who wish to not upgrade software and are happy with that, should continue to not upgrade software and be happy with that.

I am asking these questions on behalf of the people who're happy with their (ancient) version of Jitsi, who haven't paid much attention to the new versions (because it has been working fine) and whose life will suddenly get worse when FF80 hits the streets.

Because they haven't been paying attention to Jitsi's evolution, and especially its relationship to all the browsers in the world, they will be at a loss to explain what happened. At worst, they'll say, "Jitsi just got flakey the other day, so we had to switch to Zoom..."

There are many reasonable responses the potential problem:

1) We don't need to do anything, since there are only a handful of people out there with such an old version.
2) Update documentation to say, "If your Firefox users stop working..."
3) Post an issue on Github that says, "If your Firefox users stop working..."
4) Post a topic on the community forum that says, "If your Firefox users stop working..."

None of these choices require changing any code.

All of them offer a helping hand to people whose Jitsi server is about to stop working in the next few weeks. My preference would be to choose 4), but I don't have the chops to write the note. Thanks.

[jbg]

• I don't think it's "such an old version". JVB2 only went stable for people using the Debian packages in March. Plenty of people unfortunately don't maintain their servers if they're "working", so there are probably a lot of installations affected.
• Bear in mind that enforcing DTLS 1.2 will not be unique to Firefox. Chrome is likely to do it in the next few releases too; it's been discussed since early last year and is currently slated for webrtc M83.

[nils-ohlmeier]

Indeed turning off DTLS 1.0 is done by Firefox and Chrome (roughly) at the same time. So who ever wants/needs to continue to use DTLS 1.0 needs to stay on old browser versions to keep it working with their setup.
I agree that highlighting in some form of documentation why recent versions of Chrome and Firefox have stopped working seems like a good idea.

BTW Firefox users could switch to Firefox ESR to keep it working with their servers. As the current version of Firefox ESR is based on Firefox 78 it still has support for DTLS 1.0.

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