- From: Raphael Kubo da Costa via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Mar 2024 16:57:35 +0000
- To: public-geolocation@w3.org
rakuco has just submitted a new pull request for https://github.com/w3c/deviceorientation: == automation: Adapt to Generic Sensor changes to stash provided readings == Just like with w3c/sensor#487, the idea is to make it possible for users to write, for example ```js 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. See https://github.com/w3c/deviceorientation/pull/147 -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 March 2024 16:57:37 UTC