Firefox support in CallComposite

[Mrlten]

I'm not sure whether this should be considered a bug or a feature request.

Describe the bug; what happened?
Starting the CallComposite preview in Firefox results in no cameras found and the following errors in the browser console:

permissions API is not supported by browser TypeError: 'camera' (value of 'name' member of PermissionDescriptor) is not a valid value for enumeration PermissionName.
permissions API is not supported by browser TypeError: 'microphone' (value of 'name' member of PermissionDescriptor) is not a valid value for enumeration PermissionName.

According to the Azure Communication Services documentation the SDK should support Firefox, but what about the UI library?

What are the steps to reproduce the issue?

1. Start up Firefox
2. Go to the CallComposite preview
3. Enter a valid user identifier and token
4. Allow the site to use your camera and microphone
5. The CallComposite is now loaded with 'no cameras found' under the cameras dropdown. Also the camera of the live preview cannot be enabled. And lastly the mentioned errors are logged to the browser console.

What behavior did you expect?
I would expect Firefox to be supported by the UI library.

If applicable, provide screenshots:

In what environment did you see the issue?
The Storybook demo/preview site. According to a log line in the console: This Storybook was compiled for @azure/communication-react version 1.10.0-beta.1

• OS & Device: Windows on PC
• Browser: Mozilla FireFox
• Browser Version: 119.0.1

[PorterNan]

Thanks for opening this issue! Looking at our repo code, looks like we are doing some permission query in the file packages/react-composites/src/composites/CallComposite/utils/Utils.ts

Will open a bug and doing follow up investigation of fixing this!

[dmceachernmsft]

Hi @Mrlten as of right now firefox is only in public preview for the azure/communication-calling package and the UI library. As a result there will be some hiccups with the two SDK's. In the mean time until we fully support our calling experiences on the browser we recommend using another browser like Chrome, Edge or Safari depending on your platform. Please see our browser support docs here: https://learn.microsoft.com/en-us/azure/communication-services/concepts/voice-video-calling/calling-sdk-features

[JamesBurnside]

Internally we have filed work to update the UI library to fully support Firefox but as of today it is unsupported.

[jahead]

@JamesBurnside If this is going to be fixed, maybe we could leave this issue open?

As it's a useful way for us to track when firefox support will be supported - because it not 'completed' nor is it a won't fix.
I was just hit with this, and didn't find as a open issue.

Firefox support is important to our customers.

[mahdi-openup]

We have the same issue. any timeline for it?

[alkwa-msft]

(Currently doing some summer Github cleaning and I realized we unfortunately left you on a cliffhanger, and you may need to sit tight for a bit longer)

@mahdi-openup @jahead @Mrlten

Thank you for reaching out and sharing your interest in Firefox support for Azure Communication Services. At this time, Firefox is not on our immediate roadmap as we are prioritizing other key areas within Azure Communication Services.

However, we are keen to revisit this in the future and would love to gather more feedback and continue testing over the next few quarters. Your insights are invaluable to us, and we would greatly appreciate learning more about your specific customers, their use cases, and their anticipated call volumes. This information will help us better prioritize and potentially integrate Firefox support into our upcoming roadmap.

Thank you for your understanding and support. We look forward to hearing from you.

[Mrlten]

@alkwa-msft and others, at my company we've dropped the idea of using CallComposite in favor of building our own videocall component using the different ACS UI components.

We've got Firefox working reliably with the statefulCallClient / deviceManager combo. An important thing we've noticed is that if you get the cameras on Firefox using this:

await deviceManager.askDevicePermission({ video: true, audio: true });
const cameras = await deviceManager.getCameras();

The const cameras will most likely be empty (only on Firefox). The deviceManager will only return cameras of which the MediaDeviceInfo.label is set. But on Firefox there's a (small) delay between getting the device permissions and the MediaDeviceInfo labels getting set. You could add a delay between the askDevicePermission and getCameras calls but we've noticed that sometimes, even after waiting 30 seconds between those two calls, the labels still aren't set thus fetching zero available cameras.

The fix we've come up with that works reliable on Firefox is this:

await deviceManager.askDevicePermission({ video: true, audio: true });

// Asking for devices permissions again on Firefox makes sure the MediaDeviceInfo labels are set thus always getting cameras back from the getCameras() call.
if (navigator.userAgent.toLowerCase().includes('firefox')) {
    await deviceManager.askDevicePermission({ video: true, audio: true });
}

const cameras = await deviceManager.getCameras();

If I remember correctly the CallComposite doesn't use deviceManager.askDevicePermission(...) so not sure how you can fix it there.

And another thing, you will get a lot of errors in the browser console (and your favorite logging/telemetry tool), namely due to the speakers getting fetched on devices that don't support that (Firefox and most mobile browsers). That bug can be found in the CallClientProvider.tsx where the getSpeakers() call is missing a check if the browser supports fetching speakers (isSpeakerSelectionAvailable?). Also looking at that code, why are the getCameras(), getMicrophones() and getSpeakers() calls not awaited before setDeviceManager(...) is called?

[alkwa-msft]

@Mrlten thanks for the update! Great to hear you were unblocked here. The main reason why we don't officially support this time is that the underlying Calling SDK needs to do more verification on these other browsers which is why the UI Library had similar challenges in supporting Firefox.

What added more complexity when thinking about this situation is that the beta version of the UI Library Call Composite has a feature called Call Readiness which attempts to be smarter about supporting customers by directly blocking access. However with the UI components you are free to do what you want but it means you will have to do more. On the bright side it does mean more flexibility to do what you want to do.

the CallComposite does this type of coding under the hood and uses a majority of the code most developers would need to write using the calling SDK we just attempted to package it all in an easy to use way however it may seem inflexible for some customers.

While we may not officially say we support Firefox out of the box due to the issue above I am happy to refine some of your information into a Github show+tell so we can point other developers to the great information you have shared here. As for the speaker check I will run this by the team and see if we need to log this as a bug and put it into our backlog!

I really appreciate you coming back to this thread and I hope you can share other issues and findings.