automation: Adapt to Generic Sensor changes to stash provided readings #147
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Just like with w3c/sensors#487, the idea is to make it possible for
users to write, for example
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 sensortypes to "orientation event platform sensor-likes", a concept borrowed from
Generic Sensor's automation section.
Similarly to that section, the idea is that:
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 platformsensors set and retrieves any existing readings from the virtual sensor.
[[virtualSensorMapping]]
are removed from their virtual sensors'connected platform sensors set.
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 itsassociated virtual sensor when one is set.
Related to: w3c/sensors#478.
Preview | Diff