Dialog to confirm requested permissions

[yuya-oc]

Before submitting, please confirm you've

• read and understood our Contributing Guidelines
• completed Mattermost Contributor Agreement
• executed npm run lint:js for proper code formatting

Please provide the following information:

Summary
Use session.setPermissionRequestHandler() to confirm permissions when they're requested.

Results of the dialog are saved to AppData\Roaming\Mattermost\permissions.json.
This implementation is naive. The dialog pause the application until selecting a choice.

Issue link
https://mattermost.atlassian.net/browse/PLT-7458

Test Cases

1. Receive any messages in a channel.
2. A dialog should appear to confirm Allow/Deny/Skip the 'notifications' permission.
3. A desktop notification should appear after clicking 'Allow'.

Additional Notes
https://circleci.com/gh/yuya-oc/desktop/411#artifacts

[jasonblais]

Thanks @yuya-oc!

I can ask one of our designers to help with a design mock up for it.

Questions:

1. What options do we have for the popup? E.g. we could have

• popup in the middle
• popup in top left corner similar to browsers
• popup, perhaps similar to desktop notifications in the bottom right corner
• a bar at the top similar to the "blue bar" message sometimes displayed in Mattermost

2) The dialog pause the application until selecting a choice. Are there any improvements we can do?
3) Are there any other instances where this dialog would be needed (WebRTC video calls?)

[yuya-oc]

1. Options

• popup in the middle
• popup in top left corner similar to browsers
  Possible. But need to create a dialog with BrowserWindow instead of dialog.
• popup, perhaps similar to desktop notifications in the bottom right corner
  Currently impossible. We can't choose allow/deny in desktop notifications without native modules.
• a bar at the top similar to the "blue bar" message sometimes displayed in Mattermost
  Possible. But a little complex internal flow would be needed.

2. Improvement for The dialog pause the application until selecting a choice
   The application stops because dialog uses synchronous flow. So we can improve that by using asynchronous flow. But it would be a little complex than synchronous one.

3. Permissions:
   Sure. There are ‘media’(WebRTC), ‘geolocation’, ‘notifications’, ‘midiSysex’, ‘pointerLock’, ‘fullscreen’, ‘openExternal’.
   https://electron.atom.io/docs/api/session/#sessetpermissionrequesthandlerhandler

[jasonblais]

Hey @yuya-oc, sorry for the delay on this.

Sent you a note on pre-release and added notes on this Google presentation: https://docs.google.com/presentation/d/1uyIQxcscGzKcXPHUMMb3Rg7Loxld1ztmOE7t4d0z_nA/edit#slide=id.g28d3453657_0_16

I think we're close after a minor change to the dialog design and positioning.

Regarding 2), not sure how much work this would be? Thinking of a use case where the user receives the dialog while the app is minimized, without realizing it until much later. It could be a bad user experience if they didn't receive any notifications during this time period.

[jasonblais]

1 - I'm still evaluating the options. Will get back to you
2 - @yuya-oc How much work would it be to switch this to asynchronous flow?
3 - 👍

For the dialog, are we able to get close to the Chrome "request permission" dialog?

This would mean

• title: Mattermost App wants to:
• text: Show notifications / Use your camera and microphone
• icon: Bell for notifications / video camera for video calls (I can provide these as we use similar icons elsewhere in Mattermost)
• buttons: Allow / Block

[yuya-oc]

2 - I need to consider the case where many requests are coming. At least a day would be needed.

Dialog: It would be more complex flow because it's combination of main and renderer process though, possibe by using Popover of react-bootstrap. https://react-bootstrap.github.io/components.html#popovers

[jasonblais]

@yuya-oc How much more complex would it be?

The reason why having a "nicer" dialog would be good is that the majority of users will see this dialog (given most have desktop notifications enabled). So it's worth spending some the time to improve them. However, if it's a lot of work we can consider keeping the original design and just changing the texts.

The other dialogs we're adding (navigating to external pages, uncaught exception errors) are more rare and only a few people will ever see them.

[yuya-oc]

I feel it's difficult to describe enough in sentences... It's surely complex because two asynchronous things work together, so I need to manage the state in each processes. But the flow is almost similar in both cases.

However, I need to implement the dialog itself in addition to logical flow.

[yuya-oc]

Of course I agree to create nicer dialog.

[yuya-oc]

This is a prototype for the dialog. Icons are chosen from Bootstrap glyphicons for now. https://getbootstrap.com/docs/3.3/components/#glyphicons

[yuya-oc]

Implemented the dialog with asynchronous flow. https://circleci.com/gh/yuya-oc/desktop/471#artifacts

[jasonblais]

This looks great to me.

Just two minor questions/notes:

1. I think the text isn't quite centered with the icon. If we're not limited by Electron, maybe move it by 1px up? No worries if not possible.

2. I didn't grab a screenshot, but when you click "Allow" or "Block" there's a 1-2 second lag when the action is accepted. Not sure if we can reduce that time?

[yuya-oc]

1. It looks difficult for me. Possibly we can move it by 1px with hardcoding though, we also need to consider about other icons.

2. I noticed that point. I think it's related to React's state management though, I could not find the actual problem.

[jasonblais]

1. Sounds good
2. Okay, let's merge and see how it feels. We'll have a month to try improve it if needed.

[yuya-oc]

Rebased to solve conflicts. #600 is still working fine.