Re: [permissions] Defining a testing API

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

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.

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?

[1] https://w3c.github.io/permissions/#prompt-the-user-to-choose


On Fri, May 12, 2017 at 9:13 AM, Philip Jägenstedt <foolip@google.com> wrote:
> Alex. Gouaillard is also looking to defining a WebDriver API for
> getUserMedia() prompts. You should probably collaborate :)
>
> 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?
>
>
> On Tue, May 9, 2017 at 12:14 PM David Burns
> <david.burns@theautomatedtester.co.uk> wrote:
>>
>> Yes, these should be in a dedicated section for the specification in
>> question. If the base primatives are missing from WebDriver there should be
>> a request to get those in to build the rest. E.g. If its a door hanger we
>> can use the user prompts API (though I am not conviced that is the right API
>> but now isnt the time to bikeshed.) but if its controlling hardware (Web
>> Bluetooth as an example) then we may need something in WebDriver AND web
>> bluetooth APIs.
>>
>> David
>>
>> David Burns
>> Email: david.burns@theautomatedtester.co.uk
>> URL: http://www.theautomatedtester.co.uk/
>>
>> On Mon, May 8, 2017 at 4:20 PM, Mike Pennisi <mike@bocoup.com> wrote:
>>>
>>> > One of the topics we discussed was an API for dealing with "door
>>> > hanger"
>>> > notifications --- or, in a more general sense, popups that display a
>>> > limited set of options, possibly allowing some text input. This would
>>> > cover things such as alerts for desktop notifications, allowing
>>> > geolocation, and Web Bluetooth, as these are typically presented
>>> > through
>>> > the same style of UI.
>>> >
>>> > Andreas and I sketched out a basic API which was essentially similar to
>>> > that presented for user prompts, with the option of sending additional
>>> > text and perhaps a button identifier when accepting the prompt.
>>>
>>> This sounds like a necessary capability for testing, but I don't think it
>>> can be designed in advance of a standard mechanism for specifying these
>>> prompts (certainly not their look-and-feel, but at least their input
>>> elements and their effects).
>>>
>>> Up until now, I have been assuming that the Permissions specification was
>>> the appropriate place to address this. If there are use cases for rich
>>> browser-provided prompts beyond permissions, maybe it makes sense to
>>> define
>>> them in a dedicated spec instead. Does that sound right to you?
>>>
>>>
>>> On Mon, May 8, 2017 at 4:32 AM, Simon Stewart <simon.m.stewart@gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > TL;DR: we'd love an API for this kind of thing for use with WebDriver,
>>> > and
>>> > I'm on board for trying it out.
>>> >
>>> > Longer version:
>>> >
>>> > We had a discussion about work for Level 2 of the WebDriver spec at our
>>> > face-to-face meeting in Lisbon. One of the topics we discussed was an
>>> > API
>>> > for dealing with "door hanger" notifications --- or, in a more general
>>> > sense, popups that display a limited set of options, possibly allowing
>>> > some
>>> > text input. This would cover things such as alerts for desktop
>>> > notifications, allowing geolocation, and Web Bluetooth, as these are
>>> > typically presented through the same style of UI.
>>> >
>>> > Andreas and I sketched out a basic API which was essentially similar to
>>> > that
>>> > presented for user prompts, with the option of sending additional text
>>> > and
>>> > perhaps a button identifier when accepting the prompt. I'm sure Andreas
>>> > will
>>> > correct my recollection if it's not quite right.
>>> >
>>> > Other than solving the general case, the other option is (as you say)
>>> > to use
>>> > the WebDriver extension mechanisms to add specific and focused APIs for
>>> > each
>>> > spec. If you'd like a member of the group working on WebDriver to
>>> > provide
>>> > some help, I'm sure we'd be able to offer some.
>>> >
>>> > Kind regards,
>>> >
>>> > Simon
>>> >
>>> > On Wed, May 3, 2017 at 9:03 PM, Mike Pennisi <mike@bocoup.com> wrote:
>>> >>
>>> >> Hello all,
>>> >>
>>> >> The Permissions specification operates on state that cannot be
>>> >> influenced
>>> >> in
>>> >> a way that is both standard and automated. This is largely by design.
>>> >> Permission fundamentally originates from the user, so allowing
>>> >> arbitrary
>>> >> code to control it doesn't make much sense.
>>> >>
>>> >> ...in production settings. There is an important use case for
>>> >> controlling
>>> >> state programmatically: automated tests.
>>> >>
>>> >> The ability to write automated tests for the Permissions API would
>>> >> allow
>>> >> shared test suites like Web Platform Tests [1] to promote consistency
>>> >> among
>>> >> browsers, and it would also allow application developers to more
>>> >> thoroughly
>>> >> test their own code.
>>> >>
>>> >> The Permissions API isn't the only web standard that would benefit
>>> >> from
>>> >> dedicated testing support. All of the spec's "powerful features" are
>>> >> in a
>>> >> similar position. In all cases, programmatic control is undesirable
>>> >> for
>>> >> production settings but essential for conformance testing and
>>> >> application
>>> >> testing.
>>> >>
>>> >> This is currently being discussed on the public-test-infra mailing
>>> >> list
>>> >> [2],
>>> >> specifically in the context of the developing Web Bluetooth API. In
>>> >> that
>>> >> thread, we're considering two very different approaches:
>>> >>
>>> >> 1. Each standard defines a JavaScript API for testing with the
>>> >> understanding
>>> >>    that it is only to be enabled under highly-controlled circumstances
>>> >> 2. Each standard includes extensions to the WebDriver specification
>>> >> using
>>> >>    the mechanism it defines for this purpose [3]
>>> >>
>>> >> Members of the Chromium team have prototyped a straw man
>>> >> implementation of
>>> >> the first approach for the Web Bluetooth API. I'm personally
>>> >> interested in
>>> >> exploring the second approach. I think that the relatively small
>>> >> internal
>>> >> state of the Permissions API make it a great candidate for
>>> >> experimentation
>>> >> along these lines.
>>> >>
>>> >> Before getting started on a patch, I wanted to gauge interest from
>>> >> those
>>> >> involved with the specification. How do folks here feel about trying
>>> >> this
>>> >> out?
>>> >>
>>> >> Mike Pennisi
>>> >>
>>> >> Bocoup
>>> >>
>>> >> [1] https://github.com/w3c/web-platform-tests
>>> >> [2]
>>> >>
>>> >> https://lists.w3.org/Archives/Public/public-test-infra/2017AprJun/0018.html
>>> >> [3] https://w3c.github.io/webdriver/webdriver-spec.html#extensions
>>> >
>>> >
>>
>>
>

Received on Friday, 12 May 2017 14:54:55 UTC