W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2017

Re: [permissions] Defining a testing API

From: Mike Pennisi <mike@bocoup.com>
Date: Mon, 8 May 2017 11:20:46 -0400
Message-ID: <CAE1MNCzZVibm1F64oJz3z-B7upiEojyxX=XPK8KY19Rs3ekhrA@mail.gmail.com>
To: Simon Stewart <simon.m.stewart@gmail.com>
Cc: public-webappsec@w3.org, David Burns <david.burns@theautomatedtester.co.uk>, Philip J├Ągenstedt <foolip@google.com>, James Graham <james@hoppipolla.co.uk>, Boaz Sender <boaz@bocoup.com>
> 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 Monday, 8 May 2017 15:21:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:23 UTC