Re: [permissions] Defining a testing API

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

Received on Wednesday, 24 May 2017 08:13:46 UTC