automation: Adapt to Generic Sensor changes to stash provided readings

[rakuco]

Closes: none (but related to w3c/sensors#487)

The following tasks have been completed:

• Modified Web platform tests (link to pull request) (existing tests already rely on this behavior)

Implementation commitment:

• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=1891249)
• WebKit (https://bugs.webkit.org/show_bug.cgi?id=272589)
• Chromium (already implements this behavior)

---

Just like with w3c/sensors#487, the idea is to make it possible for
users to write, for example

await test_driver.create_virtual_sensor(...);
await test_driver.update_virtual_sensor(...);
window.addEventListener('deviceorientation', ...);

and receive the readings above even if the connection to the virtual sensor
was made only after the addEventListener() call. Previously, users would
need to carefully order the calls to addEventListener(),
update_virtual_sensor() and possibly even need to add a dummy event listener
first to get everything to work correctly.

Unfortunately, just as with w3c/sensor#487 this requires quite a few
changes, even more so in this specification, which is quite vague when it
comes to connecting to sensors and the lifetimes of such connections.

Some of that behavior is now specified for the virtual sensors case, so that
each Document has a [[virtualSensorMapping]] that maps virtual sensor
types to "orientation event platform sensor-likes", a concept borrowed from
Generic Sensor's automation section.

Similarly to that section, the idea is that:

• Whenever the user agent needs to connect to the underlying hardware
  because addEventListener() was called, it first attempts to find a virtual
  sensor, get/create an orientation event platform sensor-like, adds it to
  [[virtualSensorMapping]] and to the virtual sensor's connected platform
  sensors set and retrieves any existing readings from the virtual sensor.
• When a Document is being unloaded, all platform sensor-likes in
  [[virtualSensorMapping]] are removed from their virtual sensors'
  connected platform sensors set.
• Similarly, when a virtual sensor is removed, any platform sensor-likes in
  its connected platform set have their associated "device sensor" set to
  null.

In the rest of the spec, we switch from attempting to derive a virtual
sensor from the top-level traversable directly to trying to find a suitable
platform sensor-like entry in [[virtualSensorMapping]] and checking its
associated virtual sensor when one is set.

Related to: w3c/sensors#478.

---

Preview | Diff

[rakuco]

@reillyeon PTAL. The Generic Sensor side of this change looks OK to me, but, as usual, trying to apply the same ideas to this specification leads to a lot of hand-waving and hoping that things make sense.

[reillyeon]

Can you update the PR description to include the new pull request template and link to the Chromium issue where the behavior you are specing here was implemented and make sure there are WebKit and Gecko issues for implementing the sensor automation interface as well?

[reillyeon]

@rakuco have you had a chance to file issues with the other implementers of the DeviceOrientation Events API asking about implementing this automation interface?

[rakuco]

@rakuco have you had a chance to file issues with the other implementers of the DeviceOrientation Events API asking about implementing this automation interface?

Oops, thanks for the reminder. I'll get back to this issue this week.

[rakuco]

@reillyeon done. I've updated the PR message to include the contents of .github/PULL_REQUEST_TEMPLATE.md at the top and filed bugs for Gecko and WebKit (dunno if this is enough to tick the corresponding checkboxes).

Do note that this should be reviewed together with w3c/sensors#478.