1494172 - [macOS] Add UI to inform user camera/mic/screen-sharing unavailable due to OS permissions

Status: NEW

(Firefox :: Site Permissions, enhancement, P3)

Description

[Haik Aftandilian [:haik]]

This is a macOS 10.14-specific enhancement request to improve the user experience when the user has granted a site permission to access the camera/mic, but Firefox has been denied access to the camera/mic at the OS level.

Specifically, (as discussed on bug 1479051), the intent is to show the user a visual indication that the site is attempting to use the camera (as allowed by the user) but Firefox doesn't have OS access AND if possible, provide a button to trigger opening the appropriate macOS settings panel.

See bug 1479051 which is in progress and should cover 1) triggering the OS permission dialog after the Firefox site permissions dialog and 2) returning an error to the site when Firefox doesn't have the required OS permission.

See bug 1470833 which adds a Firefox-specific text label to the macOS 10.14 camera/mic dialog.

The platform support for triggering the macOS permission dialog for the camera and mic were added in bug 1487204 and is already in the tree.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

This looks like mostly UX doable without any new Core support. If not, please open dependent bugs for any changes needed in Core.

That said, UX can take a while. How strongly do we feel we need this to ship? What would be the impact of shipping without this?

Comment 2

[Haik Aftandilian [:haik]]

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #1)
> That said, UX can take a while. How strongly do we feel we need this to
> ship? What would be the impact of shipping without this?

Note that macOS Mojave is now released and we should inspect its usage to ramp up.

The impact of shipping without this is that users could get into a situation where the camera doesn't work due to access permissions and the user doesn't understand why, leaving them with a poor impression of Firefox. Without any supporting data, I suspect most users will click "OK" on the OS dialog to grant Firefox access to the camera. The same issue will apply to Chrome, but not Safari because Safari doesn't trigger the OS permission dialog.

But bug 1479051 should help with this because an error will be returned to the site from the getUserMedia() call allowing the site to display an error message.

Comment 3

[Johann Hofmann [:johannh]]

Attachment: Doorhanger mock

I agree that this shouldn't be low priority and it also affects geolocation, so a bunch of permissions are potentially breaking here.

The UX part could actually be relatively simple, we "just" need a content strategist to come up with a few lines for the doorhanger content and the button. I've attached an example of how it could look like. (Just mocked up by calling the PopupNotifications API).

Meridel, do you think you can quickly help us here (or point us to someone who can?).

I'm not sure whether we really need the flashing red indicator, though, it's more of a security notice (we're recording something) right now. The flashing red icon as I see it mimics the common "recording" sign at camcorders and similar symbols are used in camera apps. Overriding that behavior to mean something else as well (crossed out or not) is kinda dubious to me.

Why can't we just pop up that doorhanger whenever the site requests access? It's simpler and probably much more attention-grabbing

Comment 4

[Meridel [:meridel]]

Since this has to do with Preferences, I am redirecting to Michelle.

Comment 5

[Bram Pitoyo [:bram]]

Hi Johann,

In bug 1479051 comment 36, I proposed having a string like this:

> Firefox does not have access to the camera/microphone/location.
> 
> [Allow access] <-- will pop open macOS system permission dialogue


Whereas your proposal on comment 3 sounds like:

> Your system settings are preventing Firefox from accessing your camera/microphone/location. If you want to give example.com access to your camera/microphone/location, please update your preferences.
>
> [Open System Preferences] <-- will pop open macOS System Preferences


Will it be possible for us to directly invoke the system permission dialogue, instead of opening System Preferences and then relying on users to manually go to Security & Privacy > Privacy tab > Camera/Microphone/Location > Checkbox ON besides Firefox.app? This may increase the chance of users successfully completing the task.

As far as the strings go, I like saying something like you suggested – “the system is preventing Firefox from accessing” – because it clarifies the fact that it’s not a Firefox problem but a macOS problem. But it will make the strings longer and potentially harder to understand.


What about saying something like this in the doorhanger? It’s shorter, and it still says that the problem is with the OS.

> macOS has blocked Firefox from accessing your camera/microphone/location.
>
> [Allow Access] <-- pop open system permission dialogue.

Comment 6

[Bram Pitoyo [:bram]]

As these are just proposals and ‘good starting points’, I will defer to Michelle for final string.

Comment 7

[Johann Hofmann [:johannh]]

Pretty sure that that won't work (otherwise there's no point in this doorhanger at all, we could just continue to re-show the system permission thing), needinfo Haik to confirm.

Comment 8

[Haik Aftandilian [:haik]]

(In reply to Bram Pitoyo [:bram] from comment #5)
> Will it be possible for us to directly invoke the system permission
> dialogue, instead of opening System Preferences and then relying on users to
> manually go to Security & Privacy > Privacy tab > Camera/Microphone/Location
> > Checkbox ON besides Firefox.app? This may increase the chance of users
> successfully completing the task.

The way it's documented [1], once the user has denied permission, requesting permission again will not trigger the dialog so we should assume we can't. However, since upgrading to Mojave I have seen some applications triggering the dialog for Contacts access more than once. I will experiment and see if we can get the dialog to trigger after the user has already denied access. Leaving needinfo for me to verify.

The relevant part in the doc is

 "If the user has previously granted or denied recording permission, it executes the block when called; otherwise, it displays an alert and executes the block only after the user has responded to the alert."

1. https://developer.apple.com/documentation/avfoundation/avcapturedevice/1624584-requestaccessformediatype?language=objc

Comment 9

[Haik Aftandilian [:haik]]

As expected, I couldn't get the permission dialog to re-appear after I clicked deny once. I tested with browser restarts. I think we should assume that once a user has clicked deny, the dialog won't reappear until the user goes into the system settings.

Comment 10

[Bram Pitoyo [:bram]]

Can we deeply link to the “Privacy” pane of System Preferences?

The macOS help app has links like this example:
> [Open the Privacy pane for me](x-help-action://openPrefPane?bundleId=com.apple.preference.security&anchorId=Privacy)

Then what we need to do in our dialogue is teach users how to re-enable camera/mic/location.

Like this example (not final – just something to start us with):

> macOS has blocked Firefox from accessing your camera/microphone/location.
> 
> To allow access, click Camera/Microphone/Location Services, and select the tick box next to Firefox.
> 
> [Allow access] ← deeplink to System Preferences

Comment 11

[Haik Aftandilian [:haik]]

(In reply to Bram Pitoyo [:bram] from comment #10)
> Can we deeply link to the “Privacy” pane of System Preferences?

I'll look into it.

> The macOS help app has links like this example:
> > [Open the Privacy pane for me](x-help-action://openPrefPane?bundleId=com.apple.preference.security&anchorId=Privacy)
> 
> Then what we need to do in our dialogue is teach users how to re-enable
> camera/mic/location.

Or consider linking to a page on support.mozilla.org with instructions and screenshots.

Comment 12

[Bram Pitoyo [:bram]]

Sounds good. Thanks, Haik.

Yes. We have the option to link to a SUMO article, and should have a canonical SUMO link to send people to. But ideally, the user should know how to resolve the problem right where it occurs.

Comment 13

[Johann Hofmann [:johannh]]

IMO deeplinking to the relevant Privacy section of System Preferences makes most sense, since users are used to this pattern from other apps (and I can see a lot of users dropping when the button opens another webpage).

Comment 14

[Matthew N. [:MattN]]

(In reply to Johann Hofmann [:johannh] from comment #13)
> IMO deeplinking to the relevant Privacy section of System Preferences makes
> most sense, since users are used to this pattern from other apps (and I can
> see a lot of users dropping when the button opens another webpage).

I agree. We also want the ability to deep-link to this pane from JS for bug 1493103.

Comment 15

[Haik Aftandilian [:haik]]

(In reply to Haik Aftandilian [:haik] from comment #11)
> (In reply to Bram Pitoyo [:bram] from comment #10)
> > Can we deeply link to the “Privacy” pane of System Preferences?
> 
> I'll look into it.

We can definitely open the "Security & Privacy" preferences pane. On Mac, we already have some instances of Firefox opening preference panes and the low-level support is implemented in nsMacSharingService.mm

Opening "Security & Privacy" looks straightforward and would be the equivalent of running the following command from the terminal.

  open /System/Library/PreferencePanes/Security.prefPane/

However, (ideally) we would also want to select the Privacy tab and then select Camera or Microphone from the list depending on the type of access needed. I don't know how to do that.

@Dale, you recently implemented something similar to this for bug 1471877 (specifically nsMacSharingService::OpenSharingPreferences()) using some undocumented magic. Do you know if we could do the same on Mojave to open "Security & Privacy" and then select the "Privacy" tab and then select either Camera or Microphone from the list? And if so how we might do that?

Comment 16

[Matthew N. [:MattN]]

https://www.felix-schwarz.org/blog/2018/08/new-apple-event-apis-in-macos-mojave#updates has a method[1] to deep-link to the "Automation" option on the left so presumably the "Privacy_Automation" portion can be tweaked to do this. I still don't have access to Mojave to test yet.

[1] [[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:@"x-apple.systempreferences:com.apple.preference.security?Privacy_Automation"]];

Comment 17

[Haik Aftandilian [:haik]]

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #16)
> https://www.felix-schwarz.org/blog/2018/08/new-apple-event-apis-in-macos-
> mojave#updates has a method[1] to deep-link to the "Automation" option on
> the left so presumably the "Privacy_Automation" portion can be tweaked to do
> this. I still don't have access to Mojave to test yet.
> 
> [1] [[NSWorkspace sharedWorkspace] openURL:[NSURL
> URLWithString:@"x-apple.systempreferences:com.apple.preference.
> security?Privacy_Automation"]];

Thanks! I tried the following from the Terminal and they both worked, opening the Camera and Microphone sections respectively.

  open x-apple.systempreferences:com.apple.preference.security?Privacy_Camera
  open x-apple.systempreferences:com.apple.preference.security?Privacy_Microphone

From what I've observed, opening the prefs after Firefox has been denied access to the device results in Firefox being listed. Given that we'd only show this after we detected the browser doesn't have access to the camera or mic, the user would see Firefox listed and would just have to check a box and follow the prompt to restart the browser. Yes, unfortunately it requires a browser restart.

Comment 18

[Dale Harvey (:daleharvey)]

Cheers Matt, yeh https://dxr.mozilla.org/mozilla-central/source/widget/cocoa/nsMacSharingService.mm#142 has the open preferences code, I got it from chrome who got it from safari so I would imagine there is a way to use it for the privacy but I dont know off the top of my head.

However Matt's thing looks much more official so would recommend going that way if possible

Comment 19

[Ethan Tseng [:ethan]]

Johann, please correct the priority if not appropriate.

Comment 20

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

With macOS 10.15 this same problem extends to screen-sharing and getDisplayMedia as well.

Comment 22

[Matthew N. [:MattN]]

In bug 1615134 I'm adding an API to open the specific preference section (using the x-apple.systempreferences scheme from comment 16 behind the scenes).

Comment 23

[:prathiksha]

I don't have time to work on this at the moment.

Comment 24

[Rob Wu [:robwu]]

The title contains 10.14, but this is not specific to that version. I have the same issue on macOS 11.5.2 (Big Sur).

I've also posted some more observations at https://bugzilla.mozilla.org/show_bug.cgi?id=1719042#c8

Comment 25

[Haik Aftandilian [:haik]]

Affects 10.14+

Comment 26

[Paul Zühlcke [:pbz]]

The current UX around this seems pretty bad. I don't have a macOS machine, only a very clunky VM so I can't really work on this efficiently.
I'll move this to the backlog. For new installations with unset permissions, the system permission dialog will still be shown.