Re: [permissions] Defining a testing API

Hi,

Thanks for preparing the document. I've added a couple of comments to it.

Do we feel the best place to have the discussion is in the comments of that
doc, or here in this thread? I'm happy either way, but (ignoring extensive
evidence to the contrary) I'm not fond of repeating myself :)

Cheers,

Simon

On Mon, May 29, 2017 at 4:45 PM, Philip Jägenstedt <foolip@google.com>
wrote:

> Thanks for preparing that doc, Mike! I've commented and asked for some
> discussion of the options and which we should pursue first.
>
> On Wed, May 24, 2017 at 11:41 PM Alexandre GOUAILLARD <
> agouaillard@gmail.com> wrote:
>
>> Hi guys,
>>
>> same on my side, nothing before june 1st. Sorry about the inconvenience.
>>
>> On Thu, May 25, 2017 at 12:21 AM, Mike Pennisi <mike@bocoup.com> wrote:
>>
>>> Understood. Thanks, Simon
>>>
>>> On 05/24/2017 04:13 AM, Simon Stewart wrote:
>>>
>>> Hi,
>>>
>>> It's going to be at least a week until I can look at this, but I'll do
>>> so as soon as I can.
>>>
>>> Kind regards,
>>>
>>> Simon
>>>
>>> On Tue, May 23, 2017 at 8:55 PM, Mike Pennisi <mike@bocoup.com> wrote:
>>>
>>>> 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> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> Alex. Gouaillard, PhD, PhD, MBA
>> ------------------------------------------------------------
>> ------------------------
>> President - CoSMo Software Consulting, Singapore
>> ------------------------------------------------------------
>> ------------------------
>> sg.linkedin.com/agouaillard
>>
>>    -
>>
>>