Re: [w3c/permissions] Support minimizable request UI with permissions.request() (#76)

> On 12 Apr 2016, at 10:33 AM, Matt N. <notifications@github.com> 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
> 


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/76#issuecomment-208833951

Received on Tuesday, 12 April 2016 10:17:32 UTC