I didn't originally intend to make such big changes, but it was impossible to add a fix for #478 without also dealing with the inconsistencies in how platform sensors were defined.
From the larger commit of the bunch:
As described in #478, the current behavior is underspecified and allows
implementations to discard readings provided to the "Update virtual sensor
reading" WebDriver endpoint when no sensors are currently registered to
receive readings.
This makes writing some tests (especially Device Orientation API ones)
harder, as one then needs to order calls in a very specific way so that a
virtual sensor is created, a sensor is activated, a virtual sensor reading
is provided and then it is consumed by a sensor. To complicate things
further, implementations may differ in when they deactivate sensors (think
page visibility handling, for example).
It is easier to mandate one specific behavior:
Readings are never discarded. They are always saved and are stored as long
as the virtual sensor exists
If there are active sensors when they are received, they are also made
available to said active sensors.
Whenever a sensor connects to a virtual sensor and wants to start
receiving readings, the virtual sensor will provide its saved reading to
it if there is one.
In practice, this means one can call test_driver.update_virtual_sensor()
before a Sensor object is even created (or a Device Orientation event
listener is added), or that if one calls Sensor.stop() followed by
Sensor.start() the previous reading will be reported again.
Making this possible requires several changes across the specification
though, as virtual sensors need to keep track of platform sensors but
platform sensors did not have their lifetime properly defined. Furthermore,
the virtual sensor changes need to be flexible enough to be possible to use
them in the Device Orientation specification, which has no concept of
platform sensors or sensor types at all.
Platform sensors:
Platform sensors are now Document-bound. Their definition in the
"Concepts" section remains more abstract, but when used in algorithms and
interacting with platform objects, they are always treated as belonging to
a Document.
This change also removes all usages of "browsing context" and finally
gets rid of all Bikeshed warnings.
Platform sensors are kept in a per-Document [[sensorMapping]] internal
slot, a map of sensor types to platform sensors. This helps with the
above, and also helps define that there is at most one platform sensor per
sensor type in a Document, which is shared by Sensor instances with the
same associated sensor type.
Virtual sensors:
The concept of "platform sensor-like" was added to account for the Device
Orientation API. It is like a platform sensor, but without the Generic
Sensor-specific parts that are not used in the Automation section (sensor
type, latest reading map, activated sensor objects).
Virtual sensors now have two more associated items: a set of platform
sensor-likes (which are notified when there is a reading), and a latest
saved reading map (self-explanatory).
When "update virtual sensor reading" is called, the stored reading now
contains a "timestamp" key, so that if a reading is sent more than once it
contains the same timestamp.
The interaction between per-document platform sensors and per-top-level
traversable virtual sensors works as follows:
When a virtual sensor exists, a platform sensor adds itself to the
former's set of connected platform sensor-likes and also sets it as its
associated device sensor.
When "set sensor settings" is called with an empty active sensor objects
set, the platform sensor removes itself from its virtual sensor's set of
connected platform sensor-likes. When the active sensor objects set is not
empty, it checks if it is being activated (i.e. the previous sampling
frequency was 0) and, if so, it retrieves the virtual sensor's latest
saved reading.
When a Document is unloaded, all platform sensors in [[sensorMapping]]
are removed from their virtual sensors' connected paltform sensor-likes
set.
When a virtual sensor is removed, any connected platform sensor-likes have
their associated device sensor set to null.
Fixes #444 (removes all remaining browsing context references).
Related to #478.
Related to #463.
I didn't originally intend to make such big changes, but it was impossible to add a fix for #478 without also dealing with the inconsistencies in how platform sensors were defined.
From the larger commit of the bunch:
As described in #478, the current behavior is underspecified and allows implementations to discard readings provided to the "Update virtual sensor reading" WebDriver endpoint when no sensors are currently registered to receive readings.
This makes writing some tests (especially Device Orientation API ones) harder, as one then needs to order calls in a very specific way so that a virtual sensor is created, a sensor is activated, a virtual sensor reading is provided and then it is consumed by a sensor. To complicate things further, implementations may differ in when they deactivate sensors (think page visibility handling, for example).
It is easier to mandate one specific behavior:
In practice, this means one can call
test_driver.update_virtual_sensor()before a Sensor object is even created (or a Device Orientation event listener is added), or that if one calls Sensor.stop() followed by Sensor.start() the previous reading will be reported again.Making this possible requires several changes across the specification though, as virtual sensors need to keep track of platform sensors but platform sensors did not have their lifetime properly defined. Furthermore, the virtual sensor changes need to be flexible enough to be possible to use them in the Device Orientation specification, which has no concept of platform sensors or sensor types at all.
Platform sensors:
[[sensorMapping]]internal slot, a map of sensor types to platform sensors. This helps with the above, and also helps define that there is at most one platform sensor per sensor type in a Document, which is shared by Sensor instances with the same associated sensor type.Virtual sensors:
The interaction between per-document platform sensors and per-top-level traversable virtual sensors works as follows:
[[sensorMapping]]are removed from their virtual sensors' connected paltform sensor-likes set.Fixes #444 (removes all remaining browsing context references). Related to #478. Related to #463.
Preview | Diff