Re: [permissions] Defining a testing API

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