Add automation support via WebDriver #124

rakuco · 2023-11-21T17:46:55Z

This PR integrates with the automation concepts defined in
https://w3c.github.io/sensors/#automation to allow providing motion or
orientation readings via virtual sensors through the WebDriver extension
commands defined there.

IMPORTANT: This does not mean that this specification requires
implementations to support the Generic Sensor API specification and its
derived specifications. Only the Automation section is being referenced, and
when necessary some algorithms and definitions are being duplicated here,
especially for Device Motion automation.

Device Orientation:

The "absolute-orientation-euler" and "relative-orientation-euler" virtual
sensor types are defined in this specification, along with a parsing
algorithm that reads alpha, beta and gamma doubles.

Device Motion:

Readings are controlled via the "accelerometer", "linear-acceleration" and
"gyroscope" virtual sensor types. They are defined in the Accelerometer
and Gyroscope specifications. A fallback path for implementations that do
not support those specs has been provided.

Fixes #122.

Preview | Diff

rakuco · 2023-11-21T17:49:50Z

@reillyeon PTAL. This depends on w3c/sensors#475.

I'm not a fan of how hand-wavy this spec is in a lot of places, and the bit in https://w3c.github.io/deviceorientation/#deviceorientation that acts on a significant change in orientation is not checking the virtual sensors.

reillyeon · 2023-11-21T21:09:20Z

index.bs

-    1. Let <var>orientation</var> be the device's <a>relative orientation</a> in the tridimensional plane.
+      1. If <var>topLevelTraversable</var>'s <a>virtual sensor mapping</a> <a for=map>contains</a> "<code>relative-orientation-euler</code>":
+          1. Let <var>virtualSensor</var> be <var>topLevelTraversable</var>'s <a>virtual sensor mapping</a>["<code>relative-orientation-euler</code>"].
+          1. If <var>virtualSensor</var>'s <a>can provide readings flag</a> is true, then set <var>platformOrientation</var> to the latest readings provided to <var>virtualSensor</var>, so that its "<code>alpha</code>" is the angle along the Z axis, "<code>beta</code>" is the angle around the X' axis, and "<code>gamma</code>" is the angle around the Y'' axis.


The explicit definition of the axis mapping seems redundant given that we do it again below. This might actually be a good way to avoid needing to specify the Euler angle virtual sensor types at all, since we're specifying that it gets mapped to "intrinsic Tait-Bryan angles Z - X' - Y''" based on whatever the platform gave us anyways.

By "specifying the Euler angle virtual sensor types at all" do you mean the bit here after "the latest readings provided to virtualSensor" or are you referring to the virtual sensor type definitions in the Automation section? The latter are required (along with the parsing algorithm) for this spec to integrate properly with the Generic Sensor automation section.

I've reordered the steps here, which might have addressed your suggestion as well.

The reordering helps, but my thought here was that we could say something along the lines of,

Let orientation be null.

If the virtual sensor mapping contains virtualSensorType,

If the can provide readings flag is true, let orientation be the latest readings provided to the virtual sensor.

Otherwise... (the existing logic which sets orientation based on the device's actual orientation)

(the existing logic which takes orientation and represents it as Tait-Bryan angles)

The point here being that since orientation is already somewhat abstract we could say that in the automation case it gets converted from a quaternion and in the non-automation case it gets converted from whatever form the platform provides (which is how it already works).

Ack. Just one thing: in the automation case, no quaternions are involved. The idea is to get those 3 doubles (alpha, beta, gamma) with no specific meaning we get via WebDriver and forward them to an absolute/relative-orientation-euler sensor, which eventually provides them to script.

You can convert between the two formats, so my proposal is that we support one virtual sensor, which we choose to either be fed values as Euler angles or a quaternion it doesn't really matter, and the reading provided to that sensor is fed to both APIs in the same way that creating a virtual accelerometer creates devicemotion events and reading events on an Accelerometer instance.

the same way that creating a virtual accelerometer creates devicemotion events and reading events on an Accelerometer instance.

Right, I think I understand your reasoning and how it'd be useful to be able to control "legacy" deviceorientation{absolute} as well as {Absolute,Relative}OrientationSensor readings with the same virtual sensor type.

My main concern is that while both devicemotion and Accelerometer provide readings with the same unit, in this case the conversion between quaternions and the specific set of intrinsic Euler angles that would require this specification to:

Take alpha/beta/gamma in "parse orientation data reading", as otherwise the burden of converting Euler angles to quaternions would fall on users.

Specify all the math for how these 3 Euler angles are supposed to be converted to a quaternion.

Later specify all the math for how to convert the quaternion data back to Euler angles when it is time to provide readings to script.

(or vice-versa if we choose the canonical format to be Euler angles)

Going from Euler angles to quaternions is somewhat trivial, but the other way around requires several steps as seen in Chromium (here and here), WebKit (which doesn't even use quaternions and converts from CMAttitude's yaw/pitch/roll Euler angles to the format used here) and Gecko.

It'a also possible to just be hand-wavy and say "convert" or "represent this quaternion as Euler angles", but I thought the idea was to try to be less hand-wavy here.

Finally, if we do go down this route I guess it doesn't make sense to have "{absolute,relative}-orientation-euler" virtual sensor types, this spec would use/define the "{absolute,relative}-orientation" types instead and have a parsing algorithm that tries to use either Euler angles or quaternions depending on the values provided, right?

In the end I'm not really sure which format will be easiest for developers but picking one is better than having two virtual sensors because it provides forward-compatibility for tests should developers adopt the Generic Sensors API. Given the broader adoption of this API it's likely easier if we define the automation in terms of Euler angles so that the values you put into the automation API match what you get in the deviceorientation event. That is even though quaternions are "more correct" and most implementations already have the conversion code because of the Android sensor API. It also helps that the formula for converting between Euler angles and a quaternion is the simplest to specify.

(a9c8aa3 contains the latest commit before I rebased on top of the latest permissions-related changes. The current version of this PR has a single commit on top of the latest main branch)

Here's a possible approach that works with this spec and Orientation Sensor:

This spec reads Euler angles in the Automation section, and the "fire orientation event" section uses readings["alpha"], readings["beta"] and readings["gamma"].

This spec defines the "{relative,absolute}-orientation" virtual sensor type (no "-euler" at the end) which is shared with the Orientation Sensor spec.

The Orientation Sensor spec builds on top of this spec's Automation section.

It defines algorithms for converting between Euler angles and quaternions.

It continues to read and store readings in the "quaternion" entry of the readings map.

It modifies the "parse orientation data reading" algorithm so that it:

Always sets a "quaternion" key in addition to "alpha"/"beta"/"gamma".

If the user-provided reading has a "quaternion" property, it will be preferred over the Euler readings, which will be derived from the quaternion internally.

Otherwise, it will derive a quaternion from the Euler angles and set the "quaternion" entry accordingly.

This way, users can specify "{absolute,relative}-orientation" readings by using either quaternions or Euler angles, and all the required conversions are done transparently so that users can use either format if they are using an implementation that supports both.

w3c/orientation-sensor#83 has the Orientation Sensor side of this idea.

For posterity: I've just merged w3c/orientation-sensor#83, but the final approach differs from what I described above. Euler angles are converted to quaternions and the "quaternion" key is set, but there's no way to provide quaternions directly and have them converted to Euler angles.

See the discussion in w3c/orientation-sensor#83 (comment)

index.bs

… types here As suggested in #124 and similarly to what has been discussed in PRs #121 and #123, these definitions are shared by this specification and the Accelerometer and Gyroscope specs. Since this specification is further along the Rec track and is implemented by more engines, it makes sense to have the exported definitions here and reference them from the other specs instead.

index.bs

This adapts to w3c/deviceorientation#124 -- the Device Orientation and Orientation Sensor specifications are supposed to share the same virtual sensor types since they provide similar data (although with different units of measurement). Since the Device Orientation API has broader adoption, the definition of these sensor types have been moved there so that implementations do not need to depend on this spec to implement WebDriver integration.

Related to w3c/deviceorientation#124. Both the Device Orientation API and the Orientation Sensor specifications provide orientation data. Among other differences, the former provides the data as a set of intrinsic Tait-Bryant Euler angles, whereas the latter uses quaternions. From an automation perspective, though, it makes sense to use the same virtual sensor types for both APIs and take care of the conversions internally. The Device Orientation spec's Automation section defines steps for parsing a user-provided reading as alpha, beta, gamma numbers that adhere to the requirements laid out by the same spec. This commit augments the same "parse orientation data reading" algorithm by also setting a "quaternion" entry in the reading map that is set in two different ways: 1. If the user-provided readings contain a "quaternion" key, it is used as-is via the "parse quaternion reading" algorithm, and it is also converted to Euler angles so that the "alpha"/"beta"/"gamma" reading entries are also set. 2. Otherwise, the user-provider Euler angles are converted to a quaternion that is then used to set the "quaternion" entry in the readings map. The conversions are not trivial, so some new abstract operations have been added to aid in the process. The Euler angles to quaternion algorithm has been copied from Chromium. The quaternion to Euler angles algorithm has been copied from both Chromium and Gecko, both of which need to do this to convert Android's orientation data to a format suitable for their Device Orientation API implementations.

This PR integrates with the automation concepts defined in https://w3c.github.io/sensors/#automation to allow providing motion or orientation readings via virtual sensors through the WebDriver extension commands defined there. IMPORTANT: This does not mean that this specification requires implementations to support the Generic Sensor API specification and its derived specifications. Only the Automation section is being referenced, and when necessary some algorithms and definitions are being duplicated here, especially for Device Motion automation. The definitions of the "accelerometer", "linear-acceleration", "gyroscope", "absolute-orientation", and "relative-orientation" virtual sensor types have been moved here from their original specifications. As suggested in #124 and similarly to what has been discussed in PRs #121 and #123, since this specification is further along the Rec track and is implemented by more engines, it makes sense to have the exported definitions here and reference them from the other specs instead. Device Motion: - Readings are controlled via the "accelerometer", "linear-acceleration" and "gyroscope" virtual sensor types. Device Orientation: - The "absolute-orientation" and "relative-orientation" virtual sensor types are defined in this specification, along with a parsing algorithm that reads alpha, beta and gamma doubles. Compared to device motion, however, we have an additional problem in that device orientation data is provided in Euler angles and Orientation Sensor uses quaternions. The idea is to parse readings by reading alpha/beta/gamma keys from the WebDriver extension command and use them in the "fire orientation event" algorithm and skip using quaternions altogether. The Orientation Sensor spec can then augment the "parse orientation data reading" algorithm with the required steps to both 1) accept a "quaternion" key in the WebDriver extension command (and convert it to Euler angles as well) and 2) derive a quaternion from the alpha/beta/gamma Euler angles. Fixes #122.

reillyeon

LGTM with a nit

index.bs

This PR integrates with the automation concepts defined in https://w3c.github.io/sensors/#automation to allow providing motion or orientation readings via virtual sensors through the WebDriver extension commands defined there. IMPORTANT: This does not mean that this specification requires implementations to support the Generic Sensor API specification and its derived specifications. Only the Automation section is being referenced, and when necessary some algorithms and definitions are being duplicated here, especially for Device Motion automation. The definitions of the "accelerometer", "linear-acceleration", "gyroscope", "absolute-orientation", and "relative-orientation" virtual sensor types have been moved here from their original specifications. As suggested in #124 and similarly to what has been discussed in PRs #121 and #123, since this specification is further along the Rec track and is implemented by more engines, it makes sense to have the exported definitions here and reference them from the other specs instead. Device Motion: - Readings are controlled via the "accelerometer", "linear-acceleration" and "gyroscope" virtual sensor types. Device Orientation: - The "absolute-orientation" and "relative-orientation" virtual sensor types are defined in this specification, along with a parsing algorithm that reads alpha, beta and gamma doubles. Compared to device motion, however, we have an additional problem in that device orientation data is provided in Euler angles and Orientation Sensor uses quaternions. The idea is to parse readings by reading alpha/beta/gamma keys from the WebDriver extension command and use them in the "fire orientation event" algorithm and skip using quaternions altogether. The Orientation Sensor spec can then augment the "parse orientation data reading" algorithm with the required steps to both 1) accept a "quaternion" key in the WebDriver extension command (and convert it to Euler angles as well) and 2) derive a quaternion from the alpha/beta/gamma Euler angles. Fixes #122.

rakuco · 2024-01-04T15:29:39Z

Thank you for the review, @ReillyG!

SHA: 96a3179 Reason: push, by rakuco Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

…ATION Adapt to w3c/deviceorientation#124, which added an exported `dfn` for "gyroscope virtual sensor type" to be shared by that specification and this one.

Adapt to w3c/deviceorientation#124, which added and exported `dfn`s for "accelerometer virtual sensor type" and "linear-acceleration virtual sensor type" to be shared by that specification and this one.

…77) Adapt to w3c/deviceorientation#124, which added and exported `dfn`s for "accelerometer virtual sensor type" and "linear-acceleration virtual sensor type" to be shared by that specification and this one.

…ATION (#61) Adapt to w3c/deviceorientation#124, which added an exported `dfn` for "gyroscope virtual sensor type" to be shared by that specification and this one.

This adapts to w3c/deviceorientation#124 -- the Device Orientation and Orientation Sensor specifications are supposed to share the same virtual sensor types since they provide similar data (although with different units of measurement). Since the Device Orientation API has broader adoption, the definition of these sensor types have been moved there so that implementations do not need to depend on this spec to implement WebDriver integration.

Related to w3c/deviceorientation#124. Both the Device Orientation API and the Orientation Sensor specifications provide orientation data. Among other differences, the former provides the data as a set of intrinsic Tait-Bryant Euler angles, whereas the latter uses quaternions. From an automation perspective, though, it makes sense to use the same virtual sensor types for both APIs and take care of the conversions internally. The Device Orientation spec's Automation section defines steps for parsing a user-provided reading as alpha, beta, gamma numbers that adhere to the requirements laid out by the same spec. This commit augments the same "parse orientation data reading" algorithm by also setting a "quaternion" entry in the reading map that is derived from the user-provider Euler angles. The Euler angles to quaternion algorithm has been copied from Chromium.

As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <[email protected]> Bug: 1506995, 1520912, 1520919 Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5

As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <[email protected]> Bug: 1506995, 1520912, 1520919 Validate-Test-Flakiness: skip Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5

As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <[email protected]> Bug: 1506995, 1520912, 1520919 Validate-Test-Flakiness: skip Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5229177 Commit-Queue: Raphael Kubo Da Costa <[email protected]> Reviewed-by: danakj <[email protected]> Reviewed-by: Vladimir Nechaev <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Cr-Commit-Position: refs/heads/main@{#1251287}

As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <[email protected]> Bug: 1506995, 1520912, 1520919 Validate-Test-Flakiness: skip Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5229177 Commit-Queue: Raphael Kubo Da Costa <[email protected]> Reviewed-by: danakj <[email protected]> Reviewed-by: Vladimir Nechaev <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Cr-Commit-Position: refs/heads/main@{#1251287}

As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <[email protected]> Bug: 1506995, 1520912, 1520919 Validate-Test-Flakiness: skip Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5229177 Commit-Queue: Raphael Kubo Da Costa <[email protected]> Reviewed-by: danakj <[email protected]> Reviewed-by: Vladimir Nechaev <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Cr-Commit-Position: refs/heads/main@{#1251287}

As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <[email protected]> Bug: 1506995, 1520912, 1520919 Validate-Test-Flakiness: skip Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5229177 Commit-Queue: Raphael Kubo Da Costa <[email protected]> Reviewed-by: danakj <[email protected]> Reviewed-by: Vladimir Nechaev <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Cr-Commit-Position: refs/heads/main@{#1251287}

Since w3c/deviceorientation#124 and w3c/orientation-sensor#83, there are no specifications using this algorithm anymore.

…aternions from WebDriver, a=testonly Automatic update from web-platform-tests sensors: Read Euler angles instead of quaternions from WebDriver As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <[email protected]> Bug: 1506995, 1520912, 1520919 Validate-Test-Flakiness: skip Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5229177 Commit-Queue: Raphael Kubo Da Costa <[email protected]> Reviewed-by: danakj <[email protected]> Reviewed-by: Vladimir Nechaev <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Cr-Commit-Position: refs/heads/main@{#1251287} -- wpt-commits: 95e6ad02194b81f525bdaa089f4574796a68d52d wpt-pr: 44145

…aternions from WebDriver, a=testonly Automatic update from web-platform-tests sensors: Read Euler angles instead of quaternions from WebDriver As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <juha.j.vainiointel.com> Bug: 1506995, 1520912, 1520919 Validate-Test-Flakiness: skip Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5229177 Commit-Queue: Raphael Kubo Da Costa <raphael.kubo.da.costaintel.com> Reviewed-by: danakj <danakjchromium.org> Reviewed-by: Vladimir Nechaev <nechaevchromium.org> Reviewed-by: Reilly Grant <reillygchromium.org> Cr-Commit-Position: refs/heads/main{#1251287} -- wpt-commits: 95e6ad02194b81f525bdaa089f4574796a68d52d wpt-pr: 44145 UltraBlame original commit: e959950e3a8cc09ccf196193adee5cc688066080

As a result of w3c/deviceorientation#124 and w3c/orientation-sensor#83. The reading format is alpha-beta-gamma as described in the spec. They are measured in degrees and must fall within certain ranges. Internally, however, we always perform the Euler angles to quaternions conversion at the edges (i.e. in ChromeDriver and the Internals implementation used by content_shell), so that the the CDP and //services layers remain unchanged and continue to support only quaternions and the {ABSOLUTE,RELATIVE}_ORIENTATION_QUATERNION types for simplicity. The code to convert Euler angles to quaternions was copied from SensorInspectorAgent in Blink and is available for use by any callers that need to validate Euler angles and convert them. The original code remains in place because the entirety of the SensorInspectorAgent will be removed soon due to the work on bug 1506995. The test values for the orientation-sensor web tests had to be adapted: we now provide the inputs as Euler angles. The expected values have changed slightly as we had to find Euler _and_ quaternion values that were easy enough to read. Written in collaboration with Juha Vainio <[email protected]> Bug: 1506995, 1520912, 1520919 Validate-Test-Flakiness: skip Change-Id: I047f41f172f0bbcf30c7462926cec7ae0a66d4e5 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5229177 Commit-Queue: Raphael Kubo Da Costa <[email protected]> Reviewed-by: danakj <[email protected]> Reviewed-by: Vladimir Nechaev <[email protected]> Reviewed-by: Reilly Grant <[email protected]> Cr-Commit-Position: refs/heads/main@{#1251287}

rakuco requested a review from reillyeon November 21, 2023 17:46

rakuco mentioned this pull request Nov 21, 2023

Add automation support using WebDriver #122

Closed

rakuco mentioned this pull request Nov 21, 2023

Automation: Remove "virtual sensor type" from virtual sensor metadata w3c/sensors#475

Merged

reillyeon reviewed Nov 21, 2023

View reviewed changes

rakuco commented Nov 22, 2023

View reviewed changes

index.bs Show resolved Hide resolved

rakuco force-pushed the webdriver-automation branch from 9d91bcc to a9c8aa3 Compare December 5, 2023 18:52

rakuco mentioned this pull request Dec 5, 2023

Automation: integrate with Device Orientation API's Automation section w3c/orientation-sensor#83

Merged

rakuco marked this pull request as ready for review December 5, 2023 18:58

reillyeon approved these changes Dec 8, 2023

View reviewed changes

index.bs Outdated Show resolved Hide resolved

rakuco force-pushed the webdriver-automation branch from a9c8aa3 to ea74dc7 Compare January 4, 2024 14:41

rakuco merged commit 96a3179 into main Jan 4, 2024
2 checks passed

rakuco deleted the webdriver-automation branch January 4, 2024 15:29

github-actions bot added a commit that referenced this pull request Jan 4, 2024

Add automation support via WebDriver (#124)

2479483

SHA: 96a3179 Reason: push, by rakuco Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

rakuco mentioned this pull request Jan 8, 2024

editorial: Use "gyroscope virtual sensor type" dfn from DEVICE-ORIENTATION w3c/gyroscope#61

Merged

rakuco mentioned this pull request Jan 8, 2024

editorial: Use some virtual sensor type dfns from DEVICE-ORIENTATION w3c/accelerometer#77

Merged

chromium-wpt-export-bot mentioned this pull request Jan 23, 2024

sensors: Read Euler angles instead of quaternions from WebDriver web-platform-tests/wpt#44145

Merged

rakuco added a commit to rakuco/sensors that referenced this pull request Jan 25, 2024

Remove the "parse quaternion reading" algorithm

a874fd6

Since w3c/deviceorientation#124 and w3c/orientation-sensor#83, there are no specifications using this algorithm anymore.

rakuco mentioned this pull request Jan 25, 2024

Remove the "parse quaternion reading" algorithm w3c/sensors#477

Merged

reillyeon pushed a commit to w3c/sensors that referenced this pull request Jan 25, 2024

Remove the "parse quaternion reading" algorithm (#477)

1e40156

Since w3c/deviceorientation#124 and w3c/orientation-sensor#83, there are no specifications using this algorithm anymore.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add automation support via WebDriver #124

Add automation support via WebDriver #124

rakuco commented Nov 21, 2023 •

edited by pr-preview bot

Loading

rakuco commented Nov 21, 2023

reillyeon Nov 21, 2023

rakuco Nov 22, 2023

rakuco Nov 22, 2023

reillyeon Nov 28, 2023

rakuco Nov 29, 2023

reillyeon Nov 29, 2023

rakuco Nov 30, 2023 •

edited

Loading

reillyeon Dec 4, 2023

rakuco Dec 5, 2023

rakuco Jan 10, 2024

reillyeon left a comment

rakuco commented Jan 4, 2024

Add automation support via WebDriver #124

Add automation support via WebDriver #124

Conversation

rakuco commented Nov 21, 2023 • edited by pr-preview bot Loading

rakuco commented Nov 21, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rakuco Nov 30, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

reillyeon left a comment

Choose a reason for hiding this comment

rakuco commented Jan 4, 2024

rakuco commented Nov 21, 2023 •

edited by pr-preview bot

Loading

rakuco Nov 30, 2023 •

edited

Loading