Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

navigator.permissions.request #48

Closed
jimmywarting opened this issue Sep 24, 2015 · 5 comments
Closed

navigator.permissions.request #48

jimmywarting opened this issue Sep 24, 2015 · 5 comments

Comments

@jimmywarting
Copy link

jimmywarting commented Sep 24, 2015

I want to give an insight on how different all the permission request works and tell the pro & con of each one them. mostly about the error feedback and what we can do about it

First one is the notification API

Notification.requestPermission(
  result => { 
    // default, denied, granted
  }
);

I think this is the worst, one single callback with a result string. And what da heck dose default mean?!
In chrome it means user dismissed the permission dialog if the default action is to prompt every time

if you dismissed then you are able to request a new permission again


Geo Location API

navigator.geolocation.getCurrentPosition(
  Geoposition => { 
    // Geoposition {
    //   coords: {...}
    //   timestamp: 1443113866865
    // }
  },
  PositionError => {
    // PositionError {
    //   code: 1-3
    //   message: "..."
    //     PERMISSION_DENIED: 1
    //     POSITION_UNAVAILABLE: 2
    //     TIMEOUT: 3
    // }
  }
);

In chrome if you dismissed the request then you think that the client has denied access forever. and you can not request any new permission until you refresh the page. unlike the other you can ask for a new permission again. So i think this one is bad. The other permission request API support asking more then once


Midi access

navigator.requestMIDIAccess([opts]).then(
  MIDIAccess => {
   // MIDIAccess {
   //   inputs: MIDIInputMap
   //   onstatechange: null
   //   outputs: MIDIOutputMap
   //   sysexEnabled: false
   // }
  }, 
  err => {
    // DOMException: An attempt was made to break through the security policy of the user agent.
  }
)

This one is the only one that returns a promise. Me like! But i don't like the error response, happens for both dissmis and deny


User Media

navigator.getUserMedia(
  opts,
  MediaStream => {
    // MediaStream {
    // ...
    // }
  },
  NavigatorUserMediaError => {
    // NavigatorUserMediaError {
    //   constraintName: ""
    //   message: ""
    //   name: "PermissionDismissedError", "PermissionDeniedError"
    // }
  }
)

Chrome went the extra mile and put a #<code.name>PermissionDismissedError on this one only and that is really grate for the developer. You can read more why this is good in a bug request over at bugzilla. I wish the rest of the permission request could give you this kind of feedback back to the developer. Especially for the geoLocation in chrome where you could accidently close the permission request and never been asked again


Summary

In Firefox you can never really dismiss a permission request, they have something called door hangers (i think) were you can "minimize" the request and respond again later in time. The button is called "Not now". I don't like this at all. the developer gets no feedback at all that the permission request was dismissed and leaves you with a "waiting for a response"... very bad if you are building a one-page application and 5 page/hours later you get a response back when this no longer is relevant

I don't like how differently all this permission API works and now we have a chance to make it right and unify the navigator.permissions.request API

And here is how i think it should work:

The navigator.permissions.request method should return a promise and the rejection should return DOMError that can speak for all of the different permission request you can make. So I wish to get a PermissionDismissedError, PermissionDeniedError and a PermissionUnavailableError and maybe a PermissionTimeoutError for geoLocation

And if you dismissed the request then you SHOULD be able to make a new request.

So something like this:

var name = {
    1: "geolocation", // opts = {timeout: 0, enableHighAccuracy: true, maximumAge: 0}
    2: "userMedia",
    3: "midi",
    4: "notification",
    5: "wakelock",
    6: "fullscreen",
    7: "nfc"
    8: "pointerlock",
    9: "requestQuota", // opts = {bytes: 999}
    10: "bluetooth"
}[1]; // or random

navigator.permissions.request({name: name}, opts)
    .then(result => {
        console.log("whoho granted");
        console.log(result.coords.latitude)
    })
    .catch( err => {

    switch (err.name){
        case "PermissionDeniedError":
            > console.log(err.message)
            > "User denied access to geolocation"

        case "PermissionDismissedError":
            > console.log(err.message)
            > "User dissmissed access to geolocation"

        case "PermissionTimeoutError":
            > console.log(err.message)
            > "Couldn't find GPS position in time"

        case "TypeError": 
            > console.log(err.message)
            > "The provided value geolocation is not a valid enum value of type PermissionName."
    }

})
@jan-ivar
Copy link
Member

In Firefox you can never really dismiss a permission request,

@jimmywarting select "Don't Share" to dismiss a Firefox permission request.

@jan-ivar
Copy link
Member

jan-ivar commented Apr 18, 2016

As I admit in #76 (comment) the Firefox permission has real UX problems filed, but those can be fixed. We shouldn't write specs to mandate workarounds for UX problems in individual browsers.

@jimmywarting
Copy link
Author

As you said @jan-ivar Firefox has bad UX problems, didn't know that but hey... Now I know.

@marcoscaceres
Copy link
Member

@jimmywarting - Just FYI, the firefox issues are being addressed... new designs are works in progress, but we are hoping to see something in the next few months that should address most issues: https://mozilla.invisionapp.com/share/AF71R266U#/screens/142999157

@marcoscaceres
Copy link
Member

closing as answered. No further action here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants