Re: [permissions] Defining a testing API

Okay, great! I've created a Google Document to begin brainstorming what this
patch would look like. If you folks could validate the scope of work I'm
proposing, then I would be happy to draft a patch for the Permissions
API. From
there, we could have a more concrete discussion via a GitHub pull request,
knowing that we were on the same page in terms of the desired outcome.

https://docs.google.com/document/d/1Oe4VhgdFnZ6ID3WGyG97n_b1khvYsRcX7T4ddNcyJ9A/edit#

I'm specifically interested in what Mounir and Simon have to say, but I'd
welcome input from anyone on the list.

Thanks!
Mike


On 05/12/2017 11:08 AM, Simon Stewart wrote:
> Inline, and to everyone this time.
>
> On Fri, May 12, 2017 at 3:54 PM, Mike Pennisi <mike@bocoup.com
> <mailto: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