W3C home > Mailing lists > Public > public-device-apis-log@w3.org > September 2018

Re: [sensors] Introduce WebDriver extension API

From: Raphael Kubo da Costa via GitHub <sysbot+gh@w3.org>
Date: Tue, 11 Sep 2018 08:16:17 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-420188054-1536653776-sysbot+gh@w3.org>
Thanks for those links, Wanming. I'd seen those concerns scattered across multiple GitHub issues and pull requests, but not the mailing list posts that dive into them in more detail.

I guess I was too terse in my other comment, so let me try to elaborate. AFAICS, there are a few different (and at times complementary) approaches when it comes to the kind of testing we're discussing here:
1. Test APIs, which are similar to what we currently do in sensors-land. We don't have a formal "Generic Sensors Testing API" spec, but the sensors tests also use fake sensors through a vendor-agnostic JS API that we specialize for Chromium.
1. WebDriver. In this case I'm thinking of ChromeDriver, which runs an HTTP server that implements the APIs in the WebDriver spec and talks to Chrome via DevTools to run those commands. Web developers and people providing client APIs wrapping the WebDriver HTTP API can then use this extension spec to use mock sensors when testing their code.
1. WPT's testdriver.js, which allows tests to click and send key events and, if I understood things correctly, does *not* use an HTTP backend to talk to WebDriver at all. Chromium's `test_driver.click()` implementation, for example, just goes through `chrome.gpuBenchmarking.pointerActionSequence()`.

In terms of code (and with Chromium in mind), for 1 one needs the JS mock stuff we currently have, for 2 one needs to implement the sensors-related HTTP endpoints in ChromeDriver, add an API for clients to use and add support for manipulating mock sensors to DevTools, and for 3 one must add some plumbing to `resources/testdriver.js` and then call an actual implementation (which we may need to write) from Blink's `testdriver-vendor.js`.

With these distinctions in mind, I'll try to rephrase my original question: how exactly is this extension API supposed to replace our current JS mock code given nothing in WPT talks to WebDriver at this point? I'd also seen the WebDriver bits in the Permissions and Reporting specs, but I couldn't see them actually being used anywhere for comparison.

GitHub Notification of comment by rakuco
Please view or discuss this issue at https://github.com/w3c/sensors/pull/369#issuecomment-420188054 using your GitHub account
Received on Tuesday, 11 September 2018 08:16:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 11 September 2018 08:16:19 UTC