[macOS 10.15] Screen sharing shouldn't require "Camera" OSX permission. Should instead raise & gate on OS "ScreenRecording" permission consistently.
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
People
(Reporter: jib, Assigned: jib)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
User Story
Attachments
(2 files)
Catalina adds OS-level "Screen Recording" permission specifically for screen sharing. But getDisplayMedia()
in Firefox asks for OS Camera permission as well, and fails to succeed without it. It should work without that permission, and not ask for it.
STRs (in Catalina):
- tccutil reset Camera
- Open https://jan-ivar.github.io/dummy/gdm.html and pick "Entire screen"
- If you get the "Screen Recording" OS dialog, click "Open System Preferences", check
☑ Firefox Nightly
and click the[Later]
button (no need to restart), and then refresh https://jan-ivar.github.io/dummy/gdm.html (you should see more choices now), and pick "Entire screen". - Click "Allow" in Firefox's screen sharing permission prompt.
Expected result:
- Live video of my entire desktop
Actual result:
- OS prompt: "Firefox" would like to access your camera.
[Don't Allow]
[OK]
- If I hit
[Don't Allow]
I getNotFoundError
. If I hit[OK]
I get live video of entire desktop.
I don't have Mojave anymore, so I don't know if Camera permission was required for screen sharing there (I'd appreciate if if someone on Mojave could check this!)
I suspect this is either a shared-codepath bug when we added the Mojave camera permission support in bug 1479051, or a holdover from Mojave, but on Catalina, screen-sharing should work fine without Camera permission.
Assignee | ||
Comment 1•5 years ago
•
|
||
This is probably not a big deal since screen capture seems to mostly be used by WebRTC sites that tend to ask for camera and mic permission way before users get to the point of requesting to present something. But it is still wrong.
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
Depends on D49217
Assignee | ||
Comment 4•5 years ago
|
||
I've added two patches to clean up current behavior a bit in two ways:
- Fail sharing of own window sans OS permission (even though OS technically allows this. It's a "scary" choice in our view).
- Trigger the OS-level prompt on window selection of "Firefox" as well, not just "Entire desktop".
This is based on thoughts in bug 1580905 comment 7.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Comment 7•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/4a248350fc01
https://hg.mozilla.org/mozilla-central/rev/503c19dcad61
Comment 8•5 years ago
|
||
This doesn't seem like the kind of fix we'd want to take in a dot release, so calling this wontfix for 70 since we're past the point of taking any RC ride-alongs. I'm not sure about the status of esr68 here - do we think this issue is important enough to that audience that we should leave this on the radar for possible uplift there still?
Assignee | ||
Comment 9•5 years ago
|
||
Do we have a lot of orgs using ESR with Macs? Doesn't seem super critical to me.
The effect of not taking this patch isn't that much: worst case, if you only ever attempt to share the "Firefox" window, it will work without OS permission, and you might never discover why you're only ever given just two choices "Firefox" and "Entire desktop" to share. But as soon as you just select "Entire desktop", you should see the OS prompt prompting you to "Go to settings" to turn on ☑ Firefox
.
This patch merely fixes this logic to show the OS prompt regardless of which of the two you select. See also comment 1.
Comment 10•5 years ago
|
||
Thanks, sounds like ESR can live without this.
Updated•3 years ago
|
Description
•