1635716 - Device Permissions blocking eachother(?) in particular case with Google Meet

Status: RESOLVED FIXED

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

Description

[teiserse]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

I entered a Google Meet meeting. I was given a prompt to give permissions to use my microphone, which I ignored, and proceeded to change the account I was using since It put me on the wrong one. I then proceeded to enable temporary microphone permissions when I had switched to the correct account.

When I proceed to enable microphone and camera permissions before changing the account I was using, the expected result occurs.

Actual results:

Nothing - no prompt about giving permissions to the camera, which means the camera does not get used/detected. If I disable the microphone permissions in this case, then the prompt to give camera permissions appears.

Expected results:

The prompt about giving camera permissions should occur right after the prompt about giving microphone permissions.

Comment 1

[Firefox Bug Husbandry Bot]

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 2

[Bodea Daniel [:danibodea]]

I have reproduced this issue with the steps in the bug description. The microphone permission request door-hanger is displayed. If allowed, the camera permission door-hanger is not displayed, the Google Meet page shows "Camera is starting" message, but the camera is stream is not showing up, nor is the door-hanger permission for the camera. This issue was reproduced in both Windows 10 and Ubuntu 18 and both desktop and laptop.
It was reproduced on all the main channels' latest versions.

Comment 3

[Dan Minor [:dminor]]

Jan-Ivar, do you mind having a look at this? I'm wondering if this is a webcompat problem because of the different camera permissions models in Firefox and Chrome. Thanks!

Comment 4

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

Doesn't look like a Firefox bug to me. Not a regression (e.g. reproes in 68esr).

Meet appears to have different logic for Firefox vs Chrome here (as evidenced by the different experience around permission in the two browsers). So this looks like simple app logic bug to me: Switching "Meet account" is not something Firefox has any idea about, and the site apparently decides to not ask for camera over it, a bug in the site.

Nothing broken on our end that I can see, though their code is obfuscated, so it's hard to prove.

Comment 5

[Dan Minor [:dminor]]

Thanks for having a look. I'm going to move this to web compat.

Comment 6

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

I take it back. After further debugging, it appears the site does call getUserMedia again twice, once for microphone, and again for camera, but only the microphone one results in a prompt and a promise resolution, the camera request does not. I'll investigate further.

Comment 7

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

STRs:

1. Open https://jsfiddle.net/jib1/s782to93/
2. wait 1 second.
3. Answer mic prompt

Expected result:

• camera prompt

Actual result:

• No camera prompt.

Comment 8

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

Attachment: Bug 1635716 - Test that pending gUM requests are removed on navigation.

Comment 9

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

Attachment: Bug 1635716 - Remove pending gUM requests on navigation.

Depends on D75631

Comment 10

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

Hmm, the new test permafails on all platforms except macOS where it's all green. 😕

Comment 11

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

Ah, this is why.

Comment 12

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

[Tracking Requested - why for this release]: WFH — Joining Hangouts or Google Meet meeting without already being logged into your google account, OR changing Google account to enter with, breaks camera sharing in the content process.

Once broken, it can be hard to recover, especially with many tabs open. Just refreshing the page won't work, leaving users stuck.

Workaround:

• Close ALL tabs of the affected content process, and/or re-open page in a tab of a different (unharmed) content process.

This affects any site requesting microphone & camera back-to-back individually instead of together, where the first prompt is interrupted by navigation.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a831148be8d2
Test that pending gUM requests are removed on navigation. r=ng
https://hg.mozilla.org/integration/autoland/rev/3cd7c236df0e
Remove pending gUM requests on navigation. r=ng

Comment 14

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/a831148be8d2
https://hg.mozilla.org/mozilla-central/rev/3cd7c236df0e

Comment 15

[Pascal Chevrel:pascalc]

Jan-Ivar, is that upliftable to beta?

Comment 16

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

Comment on attachment 9149523 [details]
Bug 1635716 - Remove pending gUM requests on navigation.

Beta/Release Uplift Approval Request

• User impact if declined: See comment 12.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: See comment 0 or comment 7.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Added simple and prudent cleanup that was missing.
• String changes made/needed: none

Comment 17

[Pascal Chevrel:pascalc]

Comment on attachment 9149523 [details]
Bug 1635716 - Remove pending gUM requests on navigation.

Low risk Webrtc::AV fix for Google Meet/Hangout, uplift approved for 77 beta 8, thanks.

Comment 18

[Sebastian Hengst [:aryx] (needinfo on intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/7e54014f1153
https://hg.mozilla.org/releases/mozilla-beta/rev/cc5b1a7031f5