Closed Bug 1635716 Opened 2 months ago Closed 2 months ago

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

Categories

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

Desktop
All
defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox-esr68 --- wontfix
firefox76 --- wontfix
firefox77 + fixed
firefox78 + fixed

People

(Reporter: teiserse, Assigned: jib)

References

Details

Attachments

(2 files)

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.

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.)

Severity: normal → --

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.

Status: UNCONFIRMED → NEW
Component: Untriaged → WebRTC
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → Desktop
Version: 76 Branch → Trunk

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!

Flags: needinfo?(jib)

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: nobody → jib
Severity: -- → S3
Component: Desktop → WebRTC: Audio/Video
Priority: -- → P2
Product: Web Compatibility → Core

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.

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

Ah, this is why.

[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.

Blocks: 1639021
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
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78

Jan-Ivar, is that upliftable to beta?

Flags: needinfo?(jib)

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
Flags: needinfo?(jib)
Attachment #9149523 - Flags: approval-mozilla-beta?
Attachment #9149522 - Flags: approval-mozilla-beta?

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.

Attachment #9149523 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9149522 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.