Re: Permissions store

>  Defining subsystems in detail has been paying off thus far.

Hmm I don't necessarily think we have to specify things in a lot more
detail. I really don't like the path we were heading down with defining
storage structures an so on in previous PRs.

As I think about it more, I feel fairly happy with something like what we
in the spec have today. With the exception of revoke(), the only time
permission data will change is when the user has some interaction with the
UX, so it's impossible to get away from UX being involved and the UA having
freedom. For example, what if the UA shows a prompt (in the context of a
request()) that allows the user to allow the permission for several origins
at a time? I feel like this could be done in a responsible way by a UA. In
that case I feel happy about the phrase we have: "New information about the
user’s intent". If there was no prompt, it wouldn't be nice for that to
happen, but then that's clearly not "New information about the user’s
intent".

Permissions should generally be scoped to origins by default but UAs can
have such varied UX that it's hard to spec that out in granularity.

Thanks,
Raymes

On Wed, 17 Aug 2016 at 23:26 Martin Thomson <mt@mozilla.com> wrote:

> On Wed, Aug 17, 2016 at 6:29 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >> Is the fact that there has been a click observable from script in any
> >> reliable way?  I guess that you can show popups and check if they were
> >> displayed, but that's massively annoying.
> >
> > Well, you get a click event...
>
> In practice, browsers have a window after the click event in which
> they will accept a popup.  Microtasks in the same crank of the event
> loop are definitely ok, and I believe that setTimeout(..., 0) is too,
> even though that takes a non-zero amount of time.
>
> >> Where I'm going is that this implies a new entry to the key:
> >> recent-click.  Well, if any browser wants to gate showing a prompt on
> >> having clicks.
> >>
> >> That makes .query() less reliable unless we make the recent-click
> >> state explicit.  I guess the same goes for any top-level flag.
> >
> > Presumably Chrome would return "granted" for the permission but still
> > require the gesture. Which I guess arguably doesn't make it part of
> > the key, but something else? I'm not sure to what extent that has been
> > thought through.
>
> I believe that the intent is to require a click only when showing the
> permissions prompt, not on the acquisition of the resource.  So:
>
> state==prompt: call api =>  denied
> state==prompt: click then call api => prompt shown
> state==granted: call api => success
>
> you could model this as:
>
> .request({name: "foo", click: true }) => "prompt"
> .request({name: "foo", click: false }) => "denied"
>
> Somehow, I don't think that was the intent though.
>