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

Re: [permissions] Defining a testing API

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Sat, 06 May 2017 02:04:04 -0700
Message-Id: <1494061444.3159171.967696184.0A6E0E6A@webmail.messagingengine.com>
To: Mike Pennisi <mike@bocoup.com>, public-webappsec@w3.org
Cc: Simon Stewart <simon.m.stewart@gmail.com>, david.burns@theautomatedtester.co.uk, Philip J├Ągenstedt <foolip@google.com>, James Graham <james@hoppipolla.co.uk>, Boaz Sender <boaz@bocoup.com>
That sounds like a good idea. For what it's worth, the Blink LayoutTests
are using a `setPermission()` which is mostly used as part of a helper
[1] for boring internal plumbing reasons. Eventually, `clear()` or
`clearAll()` methods could be added but so far they have not been
needed.

[1]
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/http/tests/resources/permissions-helper.js

-- Mounir

On Wed, 3 May 2017, at 13:03, Mike Pennisi 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 Saturday, 6 May 2017 09:04:37 UTC

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