Re: [permissions] Defining a testing API

Inline, and to everyone this time.

On Fri, May 12, 2017 at 3:54 PM, Mike Pennisi <mike@bocoup.com> wrote:

> > Does anyone have a rough idea of the shape for this extension yet? Would
> it
> > be reacting to permission requests, taking the place of the prompts,
> toggling
> > the permissions independent of requests, or both?
>
> Reading David's response again, I'm not so sure. My previous message was a
> little unclear, so my original question still seems relevant. I'll try to
> rephrase in a more coherent way:
>
> Simon mentioned how he and Andreas were designing an API for interacting
> with
> "door hanger" notifications. This sounds completely necessary, but I
> suggested
> that *first*, we would need a standard mechanism through which those
> notifications could be created.


As a browser vendor, or someone implementing specifications, I'd agree with
that ordering. As a user of a browser, I'd disagree: the UI is already in
place in both Chrome and Firefox (IME --- those are the browsers I use
most), and users have already been trained to look for them in those
browsers.

A standard mechanism would be lovely from an implementation point of view.


> My question was: does that mechanism need to be
> defined in a dedicated specification? It seems possible that it could be
> contained within Permissions, but if other specs need this ability in
> contexts
> other than permission management, then maybe not.
>

It needs to be defined _somewhere_. One approach would be to define it in
the Permissions specification with an eye to sharing it between different
specs if it proves generally useful. Another approach would be to define
the webdriver extensions required by the Permissions specification to be
exactly specific for that spec. Either way, I think it's best done as part
of the Permissions specification for now.

In both cases, I'd be happy to advise on the webdriver specific parts, as,
I'm sure, would others in the WG.


> If there was a standalone "Privileged User Prompt" spec, then introducing
> automation abilities there might preclude the need to do so within
> Permissions.
> In that world, Permissions would reference the "Privileged User Prompt"
> spec in
> "Prompt the user to choose" [1]. Instead of scripting the internal
> "permissions" state directly, test code would control permissions through
> scripted interaction with the notifications themselves.
>

Agreed.


> Although this would be less artificial, I'm not sure the distinction would
> matter in a practical sense. This supposed "Permissions-to-Notification"
> interface would be an implementation detail to web developers, so whether
> it
> was exercised or not probably wouldn't be observable from application code
> anyway.
>
> ...but I'm getting ahead of myself. Can anyone say whether a new
> specification
> is appropriate?
>

The lowest friction thing to do right now is to add a section in the
Permissions spec that defines the webdriver URLs and messages that would be
needed. If this WG has a F2F at TPAC, we could add this an agenda item too.

Kind regards,

Simon