If you disallow access to the camera/microphone you also disallow access to screensharing

RESOLVED INVALID

Status

()

Core
WebRTC: Audio/Video
RESOLVED INVALID
9 months ago
8 months ago

People

(Reporter: Adam Ullman, Unassigned)

Tracking

50 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 months ago
Steps to reproduce the problem:
1. Go to https://meet.tokbox.com/testingScreenshare
2. When prompted for access to camera/microphone choose "Don't Share"
3. Click the share screen button

What is the expected behavior?
You are prompted for permission to share your screen

What went wrong?
You get a permission denied error

I expected that access to screen sharing and camera would be 2 different permissions. At TokBox one of our partners has a use-case where they want to allow the user to deny access to the camera/microphone but then later allow them to share their screen.
I think this is a duplicate of bug 1037438. Could you please check with a current nightly and confirm that it's fixed for Firefox 53?
(Reporter)

Comment 2

8 months ago
Still happening in Nightly (54.0a1 (2017-02-05)).
(In reply to Adam Ullman from comment #2)
> Still happening in Nightly (54.0a1 (2017-02-05)).

Are you sure getUserMedia is actually called in that case? It seems the page waits for the camera and microphone streams before doing the getUserMedia call for screen sharing.

I verified that the code in ContentWebRTC.jsm never receives the "getUserMedia:request" notification when following your steps to reproduce.
Flags: needinfo?(adam)
(Reporter)

Comment 4

8 months ago
Yes, getUserMedia is called the first time to get access to the camera and microphone, then you click deny. Then when you click the screen share button getUserMedia should be called a second time and you straight away get the NotAllowedError.
Flags: needinfo?(adam)
(In reply to Adam Ullman from comment #4)
> Then when you click the screen share button
> getUserMedia should be called a second time

What do you mean with "should" here? Are you sure it's called? The NotAllowedError displayed to the user could be the result of the previous call cached by the page.
Component: Device Permissions → WebRTC: Audio/Video
Flags: needinfo?(adam)
Product: Firefox → Core
(Reporter)

Comment 6

8 months ago
Oops, you're right. Somewhere in the opentok SDK it's preventing it from calling getUserMedia a second time. I created a jsbin to show that it actually does work https://output.jsbin.com/beluvig
Flags: needinfo?(adam)
(Reporter)

Comment 7

8 months ago
Marking this as resolved.
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.