Commits on Mar 12, 2024

1. Explicitly associate a platform sensor to a Sensor in "Connect to Sen… …

   …sor"
   
   Sensor's description mentions that "A Sensor object has an associated
   platform sensor", but the association was never made explicitly anywhere.
   
   Related to #463.

   

   rakuco committed Mar 12, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 96a991b
   • Browse repository at this point

   Copy the full SHA

   96a991b View commit details

   Browse the repository at this point in the history

2. editorial: List all data associated to a platform sensor in one place …

   Previously, part of the data associated with a platform sensor was listed in
   the "Concepts" section and the rest was listed in the "Model" section, which
   made it confusing to follow.
   
   Keep the definitions listed in the "Concepts" section there, but also
   reference them in "Model" so that the latter contains all data associated
   with a platform sensor.
   
   This commit is marked as editorial because it only reorganizes existing
   definitions.
   
   Related to #463.

   

   rakuco committed Mar 12, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 262b705
   • Browse repository at this point

   Copy the full SHA

   262b705 View commit details

   Browse the repository at this point in the history

3. automation: Save readings set when no sensors are active …

   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.

   

   rakuco committed Mar 12, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 7c32b96
   • Browse repository at this point

   Copy the full SHA

   7c32b96 View commit details

   Browse the repository at this point in the history