[deviceorientation] Add automation support using WebDriver (#122)

rakuco has just created a new issue for https://github.com/w3c/deviceorientation:

== Add automation support using WebDriver ==
This was discussed [during TPAC 2023](https://www.w3.org/2023/09/14-dap-minutes.html). WebDriver support in the Generic Sensor API spec was fully rewritten a few months ago, and the tests in WPT are not implementation-specific anymore.

It would be good to do the same with this spec, as several existing web tests in WPT rely on Chromium Mojo JS mocks and are therefore not easily interoperable.

One idea would be to make this specification reference the automation bits in the Generic Sensor API one (in other words, implementations are not expected to implement the Generic Sensor API itself, only the WebDriver extension commands defined in https://w3c.github.io/sensors/#automation). This would make it possible to set e.g. DeviceMotionEvent data by calling `test_driver.create_virtual_sensor("accelerometer")` (and others) and `test_driver.update_virtual_sensor("accelerometer", {x: 1, y: 2, z: 3})`.

If this is a worthwhile approach, then the two opens I see at the moment are
1. What kind of virtual sensor type to use for the deviceorientation and deviceorientationabsolute events. We can clearly use "accelerometer", "linear-acceleration" and "gyroscope" for DeviceMotionEvent, but there's no clear mapping to one or more sensor types for DeviceOrientationEvent. One could require "accelerometer" and "gyroscope" for relative orientation, for example, but implementations are arguably free to obtain the Euler angles data from the platform in another manner altogether, so I'm tempted to just go with making this specification define additional virtual sensor types, "relative-orientation-data" and "absolute-orientation-data" that takes Euler angles directly.
2. At the risk of contradicting some of the statements above, using 3 separate sensors ("accelerometer", "linear-acceleration" and "gyroscope") for DeviceMotionEvent may be racy since a new event may fire while one of the sensors is still being updated. In this case, we may need to define a new virtual sensor type that takes all 3 readings at once, and leave it to the implementation to update all readings at once on the platform side.

Please view or discuss this issue at https://github.com/w3c/deviceorientation/issues/122 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 13 November 2023 17:51:35 UTC