Closed Bug 1332968 Opened 7 years ago Closed 7 years ago

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

Categories

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

Product:
Core
Component:
WebRTC: Audio/Video
Version:
50 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: adam, Unassigned)

Details

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?
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)
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
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)
Marking this as resolved.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.