Re: [permissions] Defining a testing API

+Youenn Fablet <youenn@apple.com> FYI, this will have some relevance for
WebRTC test automation.

On Thu, Jun 1, 2017 at 2:40 PM Simon Stewart <simon.m.stewart@gmail.com>
wrote:

> 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
>>>
>>>    -
>>>
>>>
>