automation: Reading updates without active Sensor instances should be stashed, not discarded

[rakuco]

This was originally discussed in https://chromium-review.googlesource.com/c/chromium/src/+/5233627, where it was argued that if https://w3c.github.io/sensors/#update-virtual-sensor-reading-command when no active Sensor instances of a given type exist, then the reading should be stashed and processed when the state changes.

In JS, this means that with e.g.

await test_driver.create_virtual_sensor('accelerometer');
await test_driver.update_virtual_sensor('accelerometer', {x: 1, y: 2, z: 3});
const sensor = new Accelerometer;
sensor.start();

A "reading" event will be fired on sensor, and the x/y/z attributes will return 1/2/3 respectively instead of the update being discarded because at the time update_virtual_sensor() (and consequently https://w3c.github.io/sensors/#update-virtual-sensor-reading-command) is invoked there is no active Accelerometer instance. This applies to other situations, such as if all sensors of a given type have been stopped, or if the page becomes hidden.

The current wording in the spec is intentionally vague -- it does not explicitly prevent the situation above from happening, but it also does not mandate that it does, so implementations are currently free to just discard readings in the situations above.

I am not entirely sure of how to fix this in the spec. One possibility would be making https://w3c.github.io/sensors/#update-virtual-sensor-reading-command stash the reading some under circumstances and getting https://w3c.github.io/sensors/#activate-a-sensor-object to use the stashed reading based on a platform sensor's activated sensor objects's size. Still:

• It is unclear how to specify "under some circumstances".
• A virtual sensor does not track which platform sensors are connected to it.
• https://w3c.github.io/sensors/#model-sensor talks about platform sensors belonging to browsing contexts, which kind of contradicts how https://w3c.github.io/sensors/#concept-platform-sensor describes a platform sensor as something more abstract and independent of origins, browsing contexts or navigables.
  • If we assume the latter definition, there needs to be a representation of different platform sensor states so that one or more algorithms can decide whether to stash readings or not.

[rakuco]

Oh yeah, and the Automation section needs to remain decoupled enough from the rest of the spec so that it can continue being used by the Device Orientation API spec...

[reillyeon]

I agree the "In an implementation-defined way, make parsedReading available so that it can be obtained by platform sensors connected to virtualSensor." step is doing a lot of heavy lifting and it would be make the current reading a property of the virtual sensor and/or platform sensor in a way that this data flow could be better defined.