1919717 - teams.microsoft.com - Microphone and camera not working despite permission being granted (missing openh264 in new profile)

Status: REOPENED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Calin Tanase]

Environment:
Operating system: Windows 10
Firefox version: Firefox 131.0/130/132

Steps to reproduce:

1. Join any teams meeting (or access this link https://teams.microsoft.com/v2/?meetingjoin=true#/l/meetup-join/19:meeting_Zjg2ZGU5NzItNDM5My00YmJhLWFhN2QtMWM5OWJkYjZmYjcy@thread.v2/0?context=%7b%22Tid%22%3a%22bdeb2b64-b8d3-4633-bf4f-9bfd1e3e45d2%22%2c%22Oid%22%3a%2290adba6a-73d7-416b-8a34-f55f34a7a608%22%7d&anon=true&deeplinkId=8e87eb8e-bba4-4b17-87a0-6f39660864cc )
2. Grant permission for Microphone/Camera when prompted.
3. Attempt to enable Camera/Microphone.

Expected Behavior:
Camera/Microphone can be enabled and works.

Actual Behavior:
Camera/Microphone cannot be enabled, buttons are grayed out. (in some cases it can be enabled but the camera preview will be blank)

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, and Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/141823

Comment 1

[Calin Tanase]

Attachment: FF vs Chrome.mp4

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Is this still happening? I am not able to reproduce it on mac or Windows 10 (Logitech BRIO camera). If you have an opportunity could you also try it in Firefox 132?

Comment 3

[Jim Mathies [:jimm]]

Working on a Mac as well in Firefox Nightly.

Comment 4

[Calin Tanase]

Attachment: Reproducing On and Off.mp4

It reproduces on and off for me and it seems to reproduce on first load every time on a clean profile. (on Windows on the latest Firefox Release, Beta and Nightly)

When only the permission for webcam is shown, it will be broken. Usually if I refresh the page it will appear to allow both microphone and webcam and it will work as expected.

Comment 5

[D. Edinger]

I have experienced this as well over the last few months when joining a meeting as an online guest (using a browser rather than the Teams app). It is intermittent for me as well, and usually resolves when I refresh. The refresh acts triggers a fresh entry into the meeting, which makes the meeting host have to manually re-admit me.

I am on Windows 11 Pro build 22631.4317.
My Firefox browser says its up to date: build 131.0.3 (64-bit).

FYI: Unfortunately I won't be able to be provide fast turnaround on testing feedback since this is the only meeting I have on Teams, and it occurs monthly.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Can you retry this? @jib has been having troubles reproducing it

Comment 8

[Calin Tanase]

Attachment: teams FF vs Chrome.mp4

With the steps to reproduce this is the behavior I'm experiencing on both latest Nightly and Release (check attachment).

On first load there's a pop-up asking "Are you sure you don't want audio or video?". I Click "OK" and then I'm prompted to allow microphone and video but the toggle is still OFF after allowing them, I have to manually turn them ON. This behavior does not reproduce on Chrome.

Comment 9

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Hi Calin, do you have multiple cameras (even virtual ones) by any chance? To check, would you mind typing this into web console and pasting the result?

(await navigator.mediaDevices.getUserMedia({video: true}), await navigator.mediaDevices.enumerateDevices())

I'm not able to repro myself. But I did notice that teams prompts for a different camera in this lobby (a virtual LogiCapture device that somehow got into my camera list in Windows only) than in the actual meeting. In my case, this other camera works, but if it didn't it might be a part of the puzzle here and perhaps explain the symptom you're seeing.

This wouldn't be the first time a "not working" problem turns out to be a website selection problem (bug 1934341 comment 3).

Comment 10

[Calin Tanase]

Attachment: Console devices info.png

No, just using the integrated webcam at the time of testing. Tried with an external webcam as well, same behavior.

Comment 11

[Jim Mathies [:jimm]]

Raised with the teams folks, waiting until we have a chance to follow up with them.

Comment 12

[Denis Lisov]

I used to have a problem like this (mic not working in Teams) and at that moment (end of May 2024) it looked like Teams did not see my microphone if the microphone was muted when the page loaded. Does not reproduce with nightlies from around that time, so I think something has changed on the Teams side since then.
Gentoo Linux, Firefox Nightly, Pipewire.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Any word from teams?

Comment 14

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: jib repro with Are you sure you don't want audio or video.png

This seems like an app logic bug.

I'm able to repro reliably on Windows 10 on first load with a clean profile. The webpage immediately shows the "Are you sure you don't want audio or video?" dialog above. The in-content camera toggle stays disabled, an end-state with no way out but to refresh the page.

I took a profile https://share.firefox.dev/3BPFBdb showing only enumerateDevices has been called (which appears successful). But the webpage has made no attempt to call getUserMedia at this point. This suggests an app logic bug.

Another way to enter this state reliably is to wait 80 seconds at the Firefox permission prompt (the app appears to implement some timeout logic).

In both cases it seems wrong to disable the button, as calling getUserMedia() would have worked fine (confirmed by typing await navigator.mediaDevices.getUserMedia({video: true, audio: true} into web console).

Comment 15

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Side-note: the other case where blank video appears is something else: Windows limits camera access to one process at a time, so examples with Firefox and Chrome racing each other side-by-side will never show camera in both (whichever happens to load first wins).

This is expected on Windows. The losing browser/webpage gets an AbortError from getUserMedia in this case after the prompt. This is distinct from NotAllowedError ahead of prompt.

I mention this to illustrate that camera access can be fickle on certain platforms, so apps are encouraged to be resilient to such failures and not treat them as fatal end-states (even permission blocks can be transient if the user clears them from the url bar).

Comment 16

[Jim Mathies [:jimm]]

We've been working with the teams group to try and figure this out.

Comment 17

[Jan Vlug]

I might be seeing similar behavior with Jitsi. It looks like this started since I used an external webcam on my laptop. But even when I disconnect it, I cannot enable a camera anymore in Jitsi.

I also tested on teams.microsoft.com, and also on that website Firefox seems not to detect the webcam.

So, I experience this problem both in Jitsi and Teams.

Comment 18

[Jeff Muizelaar [:jrmuizel]]

Are you able to reproduce this in Chrome? If not, any idea why?

Comment 19

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Hi Jan, sorry you're having issues in both Jitsi and Teams, but this sounds like a separate issue (device specific). Would you mind filing a separate bug with information about your system and camera, so we can track it separately? Also, does it work here?

Comment 20

[Jan Vlug]

I reported a separate bug: Bug 1945597.

Comment 21

[Jim Mathies [:jimm]]

Chatted with the Team team today. They are going to take a look. Key STR here -

1. Windows specific
2. Tends to happen in a clean profile (you can create these in Firefox through about:profiles)
3. Happens in the main lobby prior to entering a meeting. The dialog you see is in comment 14.

Comment 22

[Randell Jesup [:jesup] (needinfo me)]

Any updates?

Comment 23

[Maire Reavy [:mreavy]]

Hey Jim and Jan-Ivar - Have we gotten any update from MS Teams? Or any other leads? (It's been 3 months since we flagged this to them.) This is currently our third top webcompat bug (across Firefox).

Comment 24

[Jim Mathies [:jimm]]

Since this is tied to a fresh profile, I wonder if this has something to do with a missing openh264 gmp at startup. We don't prompt during the install of the plugin, you just have to wait a bit and check the plugins sections to be sure. If this is the case than this bug is less severe that it might seem.

Comment 25

[Jim Mathies [:jimm]]

Calin, would you mind testing a bit more in a fresh profile and checking the about:addons plugin section for the openh264 plugin? For more robust info you can set 'media.gmp.log.level' set to 5 and check the console for plugin update information. I'm curious if we see this after we know openh264 has been downloaded and installed.

Comment 26

[Calin Tanase]

Attachment: Old vs New meeting URL.mp4

Well, I've tested on a new profile and it showed "openh264" was getting installed and I tried reproducing the issue after the installation was finished.

Seems to work as expected now on both Release and Nightly with the old meeting link (provided in the STR) but it won't work when trying to join on new meeting links, on Chrome seems to work correctly.

Comment 27

[Calin Tanase]

Attachment: Console log Nightly v141

The console log when I tried to reproduce the issue with the new meeting link, as explained in my previous comment.

Comment 28

[Jim Mathies [:jimm]]

(In reply to Calin Tanase from comment #27)

Created attachment 9490968 [details]
Console log Nightly v141

The console log when I tried to reproduce the issue with the new meeting link, as explained in my previous comment.

This is a live.com link, which is a separate service. Not working there is known, they keep saying they will migrate these services together but so far that hasn't happened. We'll check in with them next time we get together.

Comment 29

[Randell Jesup [:jesup] (needinfo me)]

Resolving as Invalid since this is due to the short delay to install OpenH264 after installing and starting Firefox for the first time in a new profile. As per comment 28, live.com is a separate issue. Thanks for all the work and testing! Good catch Jim!

Comment 30

[Jeff Muizelaar [:jrmuizel]]

I'm not convinced this is INVALID. The user experience is still bad if you happen to run into this situation. I'll retriage as affects:few but I still think we could do better here.

Comment 31

[Jim Mathies [:jimm]]

I expect platform encoding and decoding support to mitigate this for the most part.

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