Found in
114.0a1
Affected versions
114.0a1
100.0.2

Tested platforms
Windows 10, Windows 11, Mac 12 ARM, Ubuntu 20, Ubuntu 22

Steps to reproduce

1. Login into Facebook from 2 machines, using 2 accounts
2. Make a Facebook call between the accounts
3. Click on Watch Together
4. Observe that the call is muted
5. Attempt to unmute the call

Expected result
The user should be able to press the unmute button and the call to be unmuted.

Actual result
The user is unable to unmute the call. Only temporary unmuting is possible, by pressing "M" on the keyboard. If the video is muted, then the unmute button works accordingly.

Regression range
Does not seem to be a recent regression.

Additional notes

:vsangerean, if you think that's a regression, could you try to find a regression range using for example mozregression?

Are we sure this is a Firefox bug? Does it work in Chrome?

If you set the severity field it won't show up for triage. Better to leave it blank.

On Chrome and other Chromium browsers, the user is able to unmute itself without having to mute the video before.
This issue was raised by comparing Firefox with other browsers.

Thanks, I'll look into it.

So when starting "Watch together" they disable the microphone in the event handler for the media element's "play" event.
Then when clicking the microphone icon, the track is enabled in the "click" event handler. In a microtask (queued by window.queueMicrotask) hanging off the same "click" event handler, the track is disabled again.

See this pernosco recording. Unfortunately I wasn't able to get js stacks of the calls above, but I think it still shows that it's a Facebook issue.

I wonder what's behind the microtask that leads to enabled = false again, but regardless it seems like a bug on their end.

I have pinged Facebook on this issue.

Facebook tells me they don't let Firefox users unmute permanently (outside of the push-to-talk feature) because we don't echo cancel the audio rendered from the Watch Together videos.

This is true and understandable. We'll not get to fixing this in the near time unfortunately, but I've filed and linked new bugs for this work.
I have informed Facebook of the alternative approach of rendering the audio via a MediaElementAudioSourceNode, which will get echo cancelled as it will take the same rendering path as we use to render realtime audio (from MediaStreamTracks and thereby peer connections).