Safari crashes using

I open with safari on MacOS.
Once the second participant enters the room safari crashes.
Is safari supported by Jitsi?

1 Like

It is supported … What is the version of the safari you use?

Calling @jallamsetty for help :slight_smile:

Safari 14.1.on Mac 10.14.7 Catalina

I am testing Safari 14.1.2 on macOS 10.14.7 and it doesn’t crash for me. @Fred8, are you saying the browser is crashing ? If so this need to be reported in webkit. If its the app that is reloading, please provide us the browser console logs.

Sorry for the weak description. Acutally its not the browser that crashes, but the website.

It is loaded again and crashes again. I attached the console output:
Konsole.txt (16.6 KB)

NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.

Thanks for the logs, looks like you haven’t given the browser permission to capture media from the camera and mic at the OS level. You should still be allowed to join the conference and receive audio/video from others even though you are not able to send media.

Jitsi not working on MacOS HighSiera, Safari 13.1.2, I can log in, see the other participants, but get no video or sound. Connecting with Chrome is normal. What happened?

I was able to duplicate this - Chrome user saw Safari user, but Safari user didn’t see Chrome user. Both landed successfully in the same room.

I don’t have an older version of Safari to test and I am not seeing this issue with 14.1.2. Can someone please provide me the browser console log for a call where this is happening ?

@jallamsetty Browser logs attached. Captured from both Safari and Chrome.

Safari-Console.txt (23.0 KB)

Chrome-console.txt (32.4 KB)

Safari erroneously shows Chrome user as having mic and camera off.



Hi @jallamsetty is there any update on this? This issue presents only on the latest stable (2.0.6293); previous stable (6173) worked fine.

@Freddie Looks like the Safari logs attached do not have the logs from the beginning of the call so it is hard to tell if the sources were signaled. Can you please provide the full log again ? Also, is this happening with an older version of Safari and not with the recent versions ?

@jallamsetty Attaching logs from new test. Note that call was started from Chrome client (not sure if that’s significant). I don’t have access to a more recent version of Safari, but no one has complained using more recent versions, so I don’t think it’s an issue with those.



After a MacOS-Update I tested again with Safari 14.1.2. The crash does not occur anymore in this version.

1 Like

@Freddie Unfortunately Safari logs from the beginning of the calls are lost again.

[Warning] 120 console messages are not shown.

However, from the Chrome logs, it appears that there were 3 endpoints in the call and the bridge was sending both the streams to the chrome endpoint.
Logger.js:154 2021-09-28T17:48:38.477Z [modules/RTC/BridgeChannel.js] <WebSocket.e.onmessage>: New forwarded endpoints: f0d4885d,8a12cb79

On Safari, the browser is throwing some errors on remote track additions which explains why the remote users appear audio/video muted. I can’t see the full stack trace there so its hard to figure where it is coming from. I will try to get hold of a laptop with Safari 13 and give it a try.

@jallamsetty So sorry. I don’t know why I keep losing the beginning logs. Here, one more try:

Brave-js_console.txt (46.5 KB)
Chromium-js_console.txt (1.5 KB)
Firefox-js_console.txt (285.4 KB)
Safari-js_console.txt (21.0 KB)

@Freddie Thanks for the logs. Are you joining audio and video muted on Safari ? The first 110 console messages are hidden again so I am not able to determine that from the client logs. Can you reproduce the issue when you with both audio and video on ?

@jallamsetty No, didn’t join muted on Safari. Unfortunately, Safari doesn’t provide an easy way to save the browser logs :frowning: I just tried again - hope this is better.

Console.txt (50.5 KB)

Again, it’s pertinent to note that this behavior started with 6293; I didn’t observe it in 6173 or prior. Perhaps comparing the code changes between the two could help?

@Freddie We released a new version on this morning with some Safari fixes. Can you please check if this fixes the issue that you are facing on Safari 13 ?

Thanks @jallamsetty. I just checked. Unfortunately, no it doesn’t; the issue is still there in this version on