Re: [permissions] Defining a testing API

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
<https://wiki.mozilla.org/Firefox/Projects/Doorhanger_notifications>"
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
<https://w3c.github.io/webdriver/webdriver-spec.html#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/2017A
> prJun/0018.html
> [3] https://w3c.github.io/webdriver/webdriver-spec.html#extensions
>