Support minimizable request UI with permissions.request()

[mnoorenberghe]

In Firefox, permission prompts can be easily minimized (I usually call this dismissing) to easily get them out of the user's way but if the user wants to change their mind, they can re-open the permission prompt from the address bar. For example, if a permission is requested on page load and the user doesn't have enough context to understand why the permission is requested, they can look around the site get some more context then reopen the prompt and grant permission.

On the other hand, developers doing non-conventional UI (e.g. opening a permission request onload and blacking out the page) would like to know when the prompt is minimized (e.g. to remove the blackout).

As the spec is currently written it seems like there's not a way to have both of the above behaviours as the spec seems to require a final decision be made by the user because it uses a Promise as the return value (which can't be resolved more than once).

One idea: Perhaps .request() shouldn't have a return value and authors must use a change handler to be notified of the permission changes. Sending a change of the prompt state is also not a very clear way to indicate that the prompt was minimized (since the permission was likely already in the prompt state). default as used in the notifications spec seems a bit better.

[mounirlamouri]

Firefox might consider the "minimizing" as a dismissal of the prompt. I guess that's a UA-specific decision.

Regarding the changes you asked, I believe the spec supports what you are asking for but let me know if I misunderstood:

• being aware of the user dismissing:

navigator.permission.request().then(function(p) {
  if (p.state == 'prompt') // user dismissed
});

• being aware if the user came back and changed the permission

navigator.permission.request().then(function(p) {
  p.onchange = function() {
    // new state will be in p.state
  };
});

This can even be done without requesting:

navigator.permission.query().then(function(p) {
  p.onchange = function() {
    // new state will be in p.state
  };
});

[marcoscaceres]

On 12 Apr 2016, at 10:33 AM, Matt N. [email protected] wrote:

In Firefox, permission prompts can be easily minimized (I usually call this dismissing) to easily get them out of the user's way but if the user wants to change their mind, they can re-open the permission prompt from the address bar.

This should be seen as a HUGE bug. Everyone complains about this "feature"- specially developers (see the 4 year ongoing geo bug + now everyone upset about this wrt push). It also had been shown to negatively affect users, because they can't find the permission prompt again.

For example, if a permission is requested on page load and the user doesn't have enough context to understand why the permission is requested, they can look around the site get some more context then reopen the prompt and grant permission.

On the other hand, developers doing non-conventional UI (e.g. opening a permission request onload and blacking out the page) would like to know when the prompt is minimized (e.g. to remove the blackout).

As the spec is currently written it seems like there's not a way to have both of the above behaviours as the spec seems to require a final decision be made by the user because it uses a Promise as the return value (which can't be resolved more than once).

One idea: Perhaps .request() shouldn't have a return value and authors must use a change handler to be notified of the permission changes. Sending a change of the prompt state is also not a very clear way to indicate that the prompt was minimized (since the permission was likely already in the prompt state). default as used in the notifications spec seems a bit better.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[mnoorenberghe]

This should be seen as a HUGE bug. Everyone complains about this "feature"- specially developers (see the 4 year ongoing geo bug + now everyone upset about this wrt push). It also had been shown to negatively affect users, because they can't find the permission prompt again.

I've only heard developers complain about this UX and that's likely because the WebAPIs don't notify them about minimizing and I've argued before that most developers shouldn't need to care about this as most of the permissions being used are for progressive enhancement. You and others have told me that this spec fixes the lack of notifications but from my reading of the spec it doesn't.

[mnoorenberghe]

Firefox might consider the "minimizing" as a dismissal of the prompt. I guess that's a UA-specific decision.

That would require a UX change AFAICS which I don't think the spec should force.

Regarding the changes you asked, I believe the spec supports what you are asking for but let me know if I misunderstood:

being aware of the user dismissing:

navigator.permission.request().then(function(p) {
if (p.state == 'prompt') // user dismissed
});

If we resolve the request with the "prompt" state then how will we resolve when the user re-opens the prompt and chooses to allow/deny. You can't resolve the promise more than once AFAIK.

being aware if the user came back and changed the permission

navigator.permission.request().then(function(p) {
p.onchange = function() {
// new state will be in p.state
};
});

Sure, but then authors who leave out the onchange handler would miss the accept or deny if the prompt is dismissed first which seems like a footgun. This is why I propose we remove the return value of request and force developers to use the code like below to handle changes regardless of whether it came from a request or not.

This can even be done without requesting:

navigator.permission.query().then(function(p) {
p.onchange = function() {
// new state will be in p.state
};
});

[mounirlamouri]

Having a request with two answers is very odd. For users and developers. I think the behaviour Firefox has is broken: if the permission gets hidden, the request was dismissed. If the user comes back to take an action on the request, it's not different from the user going to the settings and approve/deny a permission.

I understand where you are coming from but I do not think we should make the Permissions API less developer friendly in order to support an odd UI feature that Firefox has.

[jyasskin]

@mnoorenberghe, do you have any metrics on what fraction of permission prompts are accepted vs denied vs minimized vs dismissed, and for minimized ones what fraction are then re-opened and accepted or denied? Do you have metrics on how many people visit Page Info directly to grant a permission? My gut reaction is to say that Mounir's suggesting the right mapping of Firefox's UX to the Permissions API, but if enough people re-open minimized prompts maybe it does make sense to support them directly.

[jan-ivar]

I'm confused. The current doc says

"The initial intent of this document was to allow web applications to request and revoke permissions explicitly in addition to querying the permission status. This is an aspect of the specification that was controversial thus removed from the current document in a spirit of incremental changes: settling on a small API that can be improved. "

So the request permission algorithm is unused, yes?

[jan-ivar]

Lets not say the Firefox prompt is "dismissed" when minimized, because the minimizing is undetectable from content, and the request still unanswered. The prompt is still there for all intents and purposes, represented by a near-invisible gray mic/camera icon in the URL bar (I want you to understand the logic).

Yes, several bugs have been filed (including from me) on the poor UX, especially for users not familiar with it, but at the same time, I confess I enjoy the net behavior which discourages web sites from holding users hostage with modal permission prompts. This seems to on purpose, following some underlying principle.

I realize this spec runs afoul of this principle.

[jan-ivar]

See http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html

[jyasskin]

@jan-ivar I've sent #79 to fix that paragraph.

On the Firefox prompt, it sounds like the intent is to hide from the website the fact that the user has minimized the prompt? If that's the case, we also shouldn't add to the request() API to tell the website that the prompt is minimized. It's just that Firefox should map the existing API differently from how Mounir and I suggested. That's totally in their rights.

[mnoorenberghe]

Having a request with two answers is very odd. For users and developers. I think the behaviour Firefox has is broken: if the permission gets hidden, the request was dismissed.

It's not two answers though. "default" isn't an answer, it's just notifying about a state change so it doesn't fit as a resolution.

If the user comes back to take an action on the request, it's not different from the user going to the settings and approve/deny a permission.

I don't think we should expect UAs to have UI to proactively grant permission for a site. At least in Fx we're planning to only allow revoking from the control center (address bar panel), not allowing. This sounds like you're in favour of my suggestion… see below. I agree that all permission changes (in the prompt or from other settings UI should be treated the same and that's why I propose that the change handler should be the way to find out about them, not a separate .request() mechanism (e.g. return value).

I understand where you are coming from but I do not think we should make the Permissions API less developer friendly in order to support an odd UI feature that Firefox has.

What I'm proposing for the API is more developer friendly as it means that developers by-default catch the permission changes that happen outside the request too. It means there is only one way to know about permission changes instead of two as there currently is in the spec (from request and change).

[marcoscaceres]

Closing per #83.