Device Permissions blocking eachother(?) in particular case with Google Meet
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
People
(Reporter: teiserse, Assigned: jib)
References
Details
Attachments
(2 files)
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
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•8 months ago
|
||
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•8 months ago
|
||
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•8 months ago
|
||
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 hidden (obsolete) |
Comment hidden (obsolete) |
Assignee | ||
Comment 6•8 months ago
•
|
||
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.
Assignee | ||
Comment 7•8 months ago
|
||
STRs:
- Open https://jsfiddle.net/jib1/s782to93/
- wait 1 second.
- Answer mic prompt
Expected result:
- camera prompt
Actual result:
- No camera prompt.
Assignee | ||
Comment 8•8 months ago
|
||
Assignee | ||
Comment 9•8 months ago
|
||
Depends on D75631
Assignee | ||
Comment 10•8 months ago
|
||
Hmm, the new test permafails on all platforms except macOS where it's all green. 😕
Assignee | ||
Comment 11•8 months ago
|
||
Ah, this is why.
Assignee | ||
Comment 12•8 months ago
|
||
[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•8 months ago
|
||
Pushed by jbruaroey@mozilla.com: 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•8 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/a831148be8d2
https://hg.mozilla.org/mozilla-central/rev/3cd7c236df0e
Updated•8 months ago
|
Assignee | ||
Comment 16•8 months ago
|
||
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
Assignee | ||
Updated•8 months ago
|
Comment 17•8 months ago
|
||
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.
Updated•8 months ago
|
![]() |
||
Comment 18•8 months ago
|
||
bugherderuplift |
Updated•7 months ago
|
Description
•