1492847 - Permissions for microphone are lost after unplugging the headsets while in a call

Status: NEW

(Core :: WebRTC: Audio/Video, defect, P2)

Description

[Catalin Sasca, Desktop QA [:csasca]]

Attachment: 2018-09-20 16_13_11-.png

[Affected versions]:
- Beta 63.0b7
- Nightly 64.0a1 (2018-09-20)

[Affected platforms]:
- Windows 10 (x64)

[Steps to reproduce]:
 Prerequisites:

- A working headset is required to run this test case. The term headset refers to a device that has headphones and a microphone.
- We used USB headset, but it is reproducing with TRRS aswell. 
- 2 computers - one of them needs to have Windows 10. 

1. Plug the USB headset into the Windows 10 machine and check audio/video.
2. Plug the headset into the other machine and check audio/video.
3. Start a call on a random WebRTC service (https://appr.tc/).
4. From the other computer join the same call. 
5. Unplug and plug the headset from the Windows 10 machine and check audio/video and permissions.

[Expected result]:

The call is resumed without any issues.

[Actual result]:

Firefox is losing the permission to use the microphone after unplugging the usb headset or jack microphone, and is not resuming it after the headsets are plugged back in.

[NOTE]: 

- On Firefox 62.0, the issue is not reproducing at all, and the call can be resumed after plugging the headsets back.

- If selecting "Remember this decision" at the prompt where Firefox is asking for permissions (as it can be seen in the attachment), and then unplugging the headsets and plugging them back while in a call, the permission reappears, but the microphone is still not used.

Comment 1

[Dan Minor [:dminor]]

"Remember this decision" only remembers the decision to give permission to the site to access the microphone, it does not remember which microphone the user chose. It's possible when the usb headset is unplugged, the default switches to built in speakers / headphones, and stays that way even when the usb headset is plugged back in.

Making this a P2 as this seems like a regression from Firefox 62.

Comment 2

[Catalin Sasca, Desktop QA [:csasca]]

I'm back with the regression range:

Last good revision: d138efcfa0061239d896c306229f06a8f7398c8a
First bad revision: 67c4ed3c73d7bb770edcbdffebfb5688a3822a5b
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d138efcfa0061239d896c306229f06a8f7398c8a&tochange=67c4ed3c73d7bb770edcbdffebfb5688a3822a5b

Bug 1404977 seems to be the culprit.

Comment 3

[Nils Ohlmeier [:drno]]

Paul, since you landed bug 1404977 could you please have a look what is going wrong here?

Comment 4

[Paul Adenot (:padenot)]

I think I can reproduce a problem, but not the problem described.

A number of things to do here please:
- I never "lose permission" or something like that, I don't know what this means. Can you explain what you mean here?
- Please send a screen-cast of the issue. What does "resuming" a call mean? The call should not be stopped while the device is unplugged. The video should still be moving and that.
- On the screenshot, it looks like the page has only a temporary permission, it's not remembered. Otherwise it would say "Allowed".

Another question:

- Does this machine have only one audio device, and zero when you unplug it?

Comment 5

[Paul Adenot (:padenot)]

> - Does this machine have only one audio device, and zero when you unplug it?

Probably yes. When I only have a single audio device on the machine and I unplug it, the MediaStream now stops it seems.

Comment 6

[Catalin Sasca, Desktop QA [:csasca]]

Hi Paul. The permission disappears for the microphone (yes, that temporary permissions in the attachment) when unplugged. That happens on Windows 10 only and from Firefox >62. On the same system, the issue is not reproducing, say on Firefox 62.0.2 (Here I'm referring about the question regarding if I unplug the microphone, there will be no audio device) and the permission stays there even if the microphone is unplugged and when plugged back in, it resumes the call(the other attendee from the call can hear me back). The call isn't freezing at all, just when you plug back the microphone on Firefox >62, the other end is not hearing anything anymore, because of the lost permission, and force me to refresh the page and allow again the permissions.

Here you have a link with both 62.0.2 and 63.0b9 behaviors, here I used a headset with jack input for the microphone, unplugged then plugged back: https://drive.google.com/open?id=1eI1a_jH6GQ6sM397M0Gmat-hT-2SFSwm

Comment 7

[Pascal Chevrel:pascalc (PTO until April 26)]

Paul, did you make any progress on this one? Thanks

Comment 8

[Paul Adenot (:padenot)]

No.

Comment 9

[Pascal Chevrel:pascalc (PTO until April 26)]

OK, marking as fix-optional for 63 as this is not a P1 and we are already well advanced in our beta cycle. If you have a low-risk patch in the two weeks to come, I may consider it for uplift, thanks.

Comment 10

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late for a fix in 64. We could still take a patch for 66 or possibly 65.

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Marking this fix-optional for 66/67 since the team has assigned it a priority already.

Comment 12

[Neha Kochar [:neha]]

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

Comment 13

[Adrian Florinescu [:aflorinescu]]

Somehow, in 70.0a1 2019-07-24 and 69.0b7 20190722201635 this issue is not reproducible anymore with a facebook call for example. Firefox 68.0.1 is still affected.

Going to set ? flags for 69/70 and recheck this once again towards the end of the cycle and mark them not affected.

Comment 14

[Raluca Popovici, Desktop QA]

On Firefox Beta 69 and Nightly 70 this issue is not reproducible. Also checked in Nightly 71. I will set the flags accordingly.