From e955ea0bb05aea0a21014308a764dbfe4ef6e4a4 Mon Sep 17 00:00:00 2001 From: Mikhail Pozdnyakov Date: Wed, 28 Feb 2018 16:02:30 +0200 Subject: [PATCH] Clarify the conditions to expose sensor readings This patch consolidates all the necessary conditions to expose sensor readings to a single list at https://w3c.github.io/sensors/#can-expose-sensor-readings in order to make them more explicit and improve readability. It also brings clarifications to the Sensor model description and minor editorial changes (corrected references to the definitions from the PERMISSIONS specification). --- index.bs | 41 ++++--- index.html | 332 +++++++++++++++++++++++++++-------------------------- 2 files changed, 195 insertions(+), 178 deletions(-) diff --git a/index.bs b/index.bs index 67150fa..33346a2 100644 --- a/index.bs +++ b/index.bs @@ -75,6 +75,10 @@ urlPrefix: https://wicg.github.io/feature-policy/; spec: FEATURE-POLICY text: feature name text: policy-controlled feature text: allowed to use +urlPrefix: https://www.w3.org/TR/permissions; spec: PERMISSIONS + type: dfn + text: permission name + text: permission state -

A Sensor object has an associated platform sensor.

+

A Sensor object has an associated platform sensor.

The task source for the tasks mentioned in this specification is the sensor task source.

- In the following example, firstly, we check whether the user agent has permission to access sensor readings, then we construct accelerometer sensor and add event listeners to get events for platform sensor activation, + In the following example, firstly, we check whether the user agent has permission to access sensor readings, then we construct accelerometer sensor and add event listeners to get events for platform sensor activation, error conditions and notifications about newly available sensor readings. The example - measures and logs maximum total acceleration of a device hosting the platform sensor. + measures and logs maximum total acceleration of a device hosting the platform sensor.

The event handler event types for the corresponding Sensor Interface's event handler attributes are defined in Event handlers section.

navigator.permissions.query({ name: 'accelerometer' }).then(result => {
     if (result.state === 'denied') {
@@ -2251,19 +2257,19 @@ 

-

Note: the nodes in the diagram above represent the states of a Sensor object and they should not be -confused with the possible states of the underlying platform sensor or device sensor.

+

Note: the nodes in the diagram above represent the states of a Sensor object and they should not be +confused with the possible states of the underlying platform sensor or device sensor.

7.1.2. Sensor garbage collection

-

A Sensor object whose [[state]] is "activating" must not be garbage collected +

A Sensor object whose [[state]] is "activating" must not be garbage collected if there are any event listeners registered for "activated" events, "reading" events, or "error" events.

-

A Sensor object whose [[state]] is "activated" must not be garbage collected +

A Sensor object whose [[state]] is "activated" must not be garbage collected if there are any event listeners registered for "reading" events, or "error" events.

-

When a Sensor object whose [[state]] is "activated" or "activating" is +

When a Sensor object whose [[state]] is "activated" or "activating" is eligible for garbage collection, the user agent must invoke deactivate a sensor object with this object as argument.

7.1.3. Sensor internal slots

-

Instances of Sensor are created +

Instances of Sensor are created with the internal slots described in the following table:

@@ -2274,7 +2280,7 @@

@@ -2395,7 +2401,7 @@

exception cannot be handled synchronously.

7.1.12. Event handlers

The following are the event handlers (and their corresponding event handler event types) -that must be supported as attributes by the objects implementing the Sensor interface:

+that must be supported as attributes by the objects implementing the Sensor interface:

[[state]] - The current state of the Sensor object which is one of + The current state of the Sensor object which is one of "idle", "activating", or "activated". @@ -2283,12 +2289,12 @@

[[frequency]]

A double representing frequency in Hz that is used to calculate - the requested sampling frequency for the associated platform sensor and to define the upper bound of the reporting frequency for this Sensor object. + the requested sampling frequency for the associated platform sensor and to define the upper bound of the reporting frequency for this Sensor object.

This slot holds the provided SensorOptions.frequency value. It is initially unset.

[[lastEventFiredAt]] - The high resolution timestamp of the latest sensor reading that was sent to observers of the Sensor object, + The high resolution timestamp of the latest sensor reading that was sent to observers of the Sensor object, expressed in milliseconds that passed since the time origin. It is initially null.
@@ -2431,7 +2437,7 @@

input
-

sensor_instance, a Sensor object.

+

sensor_instance, a Sensor object.

options, a SensorOptions object.

output @@ -2445,7 +2451,7 @@

Set sensor_instance.[[frequency]] to options.frequency.

-

Note: there is not guarantee that the requested options.frequency can be respected. The actual sampling frequency can be calculated using Sensor timestamp attributes.

+

Note: there is not guarantee that the requested options.frequency can be respected. The actual sampling frequency can be calculated using Sensor timestamp attributes.

8.2. Check sensor policy-controlled features

@@ -2453,7 +2459,7 @@

input
-

sensor_type, a sensor type.

+

sensor_type, a sensor type.

output

True if all of the associated sensor feature names are allowed to use, @@ -2481,20 +2487,20 @@

input
-

sensor_instance, a Sensor object.

+

sensor_instance, a Sensor object.

output
-

True if sensor instance was associated with a platform sensor, +

True if sensor instance was associated with a platform sensor, false otherwise.

  1. -

    Let type be the sensor type of sensor_instance.

    +

    Let type be the sensor type of sensor_instance.

  2. If the device has a single device sensor which can provide readings for type, then

    1. -

      Associate sensor_instance with a platform sensor corresponding +

      Associate sensor_instance with a platform sensor corresponding to this device sensor.

    2. Return true.

      @@ -2506,7 +2512,7 @@

      If type has an associated default sensor, then

      1. -

        Associate sensor_instance with a platform sensor corresponding +

        Associate sensor_instance with a platform sensor corresponding to default sensor.

      2. Return true.

        @@ -2521,16 +2527,16 @@

        input
        -

        sensor_instance, a Sensor object.

        +

        sensor_instance, a Sensor object.

        output

        None

        1. -

          Let sensor be the platform sensor associated with sensor_instance.

          +

          Let sensor be the platform sensor associated with sensor_instance.

        2. -

          Append sensor_instance to sensor’s set of activated sensor objects.

          +

          Append sensor_instance to sensor’s set of activated sensor objects.

        3. Invoke set sensor settings with sensor as argument.

        4. @@ -2542,7 +2548,7 @@

          input
          -

          sensor_instance, a Sensor object.

          +

          sensor_instance, a Sensor object.

          output

          None

          @@ -2552,12 +2558,12 @@

          Remove all tasks associated with sensor_instance from the task queue associated with sensor task source.

        5. -

          Let sensor be the platform sensor associated with sensor_instance.

          +

          Let sensor be the platform sensor associated with sensor_instance.

        6. -

          If sensor’s set of activated sensor objects contains sensor_instance,

          +

          If sensor’s set of activated sensor objects contains sensor_instance,

          1. -

            Remove sensor_instance from sensor’s set of activated sensor objects.

            +

            Remove sensor_instance from sensor’s set of activated sensor objects.

          2. Invoke set sensor settings with sensor as argument.

          3. @@ -2572,14 +2578,14 @@

            input
            -

            sensor, a platform sensor.

            +

            sensor, a platform sensor.

            output

            None

            1. -

              Let activated_sensors be sensor’s associated set of activated sensor objects.

              +

              Let activated_sensors be sensor’s associated set of activated sensor objects.

            2. For each s of activated_sensors,

                @@ -2597,14 +2603,14 @@

                input
                -

                sensor, a platform sensor.

                +

                sensor, a platform sensor.

                output

                None

                1. -

                  If sensor’s set of activated sensor objects is empty,

                  +

                  If sensor’s set of activated sensor objects is empty,

                  1. Set requested sampling frequency to null.

                    @@ -2628,7 +2634,7 @@

                    input
                    -

                    sensor, a platform sensor.

                    +

                    sensor, a platform sensor.

                    reading, a sensor reading.

                    output @@ -2644,7 +2650,7 @@

                    reading.

                2. -

                  Let activated_sensors be sensor’s associated set of activated sensor objects.

                  +

                  Let activated_sensors be sensor’s associated set of activated sensor objects.

                3. Run these sub-steps in parallel:

                    @@ -2662,7 +2668,7 @@

                    input
                    -

                    sensor_instance, a Sensor object.

                    +

                    sensor_instance, a Sensor object.

                    output

                    reporting frequency in Hz.

                    @@ -2677,7 +2683,7 @@

                    if f is set,

                    1. -

                      set frequency to f capped by the upper and lower sampling frequency bounds for the associated platform sensor.

                      +

                      set frequency to f capped by the upper and lower sampling frequency bounds for the associated platform sensor.

                  1. Otherwise,

                    @@ -2695,7 +2701,7 @@

                    input
                    -

                    sensor_instance, a Sensor object.

                    +

                    sensor_instance, a Sensor object.

                    output

                    None

                    @@ -2758,7 +2764,7 @@

                    input
                    -

                    sensor_instance, a Sensor object.

                    +

                    sensor_instance, a Sensor object.

                    output

                    None

                    @@ -2777,7 +2783,7 @@

                    input
                    -

                    sensor_instance, a Sensor object.

                    +

                    sensor_instance, a Sensor object.

                    output

                    None

                    @@ -2788,7 +2794,7 @@

                    Fire an event named "activate" at sensor_instance.

                  2. -

                    Let sensor be the platform sensor associated with sensor_instance.

                    +

                    Let sensor be the platform sensor associated with sensor_instance.

                  3. If sensor’s latest reading["timestamp"] is not null,

                      @@ -2802,7 +2808,7 @@

                      input
                      -

                      sensor_instance, a Sensor object.

                      +

                      sensor_instance, a Sensor object.

                      error, a DOMException.

                      output @@ -2821,7 +2827,7 @@

                      input
                      -

                      sensor_instance, a Sensor object.

                      +

                      sensor_instance, a Sensor object.

                      key, a string representing the name of the value.

                      output @@ -2833,7 +2839,7 @@

                      If sensor_instance.[[state]] is "activated",

                      1. -

                        Let readings be the latest reading of sensor_instance’s related platform sensor.

                        +

                        Let readings be the latest reading of sensor_instance’s related platform sensor.

                      2. If the extension specification defines a local coordinate system for sensor_instance,

                          @@ -2852,16 +2858,16 @@

                          input
                          -

                          sensor_instance, a Sensor object.

                          +

                          sensor_instance, a Sensor object.

                          output
                          -

                          A permission state.

                          +

                          A permission state.

                          1. -

                            Let sensor be the platform sensor associated with sensor_instance.

                            +

                            Let sensor be the platform sensor associated with sensor_instance.

                          2. -

                            Let sensor_permissions be sensor’s associated set of permission names.

                            +

                            Let sensor_permissions be sensor’s associated set of permission names.

                          3. Run these sub-steps in parallel:

                              @@ -2884,9 +2890,9 @@

                              9. Extensibility

                              This section is non-normative.

                              -

                              This section describes how this specification can be extended to specify APIs for different sensor types.

                              +

                              This section describes how this specification can be extended to specify APIs for different sensor types.

                              Such extension specifications are encouraged to focus on a -single sensor type, exposing both high and low level +single sensor type, exposing both high and low level as appropriate.

                              For an up-to-date list of extension specifications, please refer to [GENERIC-SENSOR-USECASES] and [MOTION-SENSORS] documents.

                              9.1. Security and Privacy

                              @@ -2904,16 +2910,16 @@

                              9.2. Naming

                              -

                              Sensor interfaces for low-level sensors should be -named after their associated platform sensor. +

                              Sensor interfaces for low-level sensors should be +named after their associated platform sensor. So for example, the interface associated with a gyroscope -should be simply named Gyroscope. Sensor interfaces for high-level sensors should be -named by combining the physical quantity the platform sensor measures +should be simply named Gyroscope. Sensor interfaces for high-level sensors should be +named by combining the physical quantity the platform sensor measures with the "Sensor" suffix. -For example, a platform sensor measuring +For example, a platform sensor measuring the distance at which an object is from it may see its associated interface called ProximitySensor.

                              -

                              Attributes of the Sensor subclass that +

                              Attributes of the Sensor subclass that hold sensor readings values should be named after the full name of these values. For example, the Thermometer interface should hold @@ -2961,42 +2967,42 @@

                              Following the precepts of the Extensible Web Manifesto [EXTENNNNSIBLE], extension specifications should focus primarily on exposing low-level sensor APIs, but should also expose high-level APIs when they are clear benefits in doing so.

                              9.5. When is Enabling Multiple Sensors of the Same Type Not the Right Choice?

                              -

                              It is not advisable to construct multiple Sensor instances of the same sensor type with +

                              It is not advisable to construct multiple Sensor instances of the same sensor type with equal construction parameters, as it can lead to unnecessary hardware resources consumption.

                              -

                              In cases when multiple observers are interested in notifications of a newly available sensor reading, an event listener can be added on a single Sensor instance instead of -creating multiple instances of the same sensor type and using simple onreading event +

                              In cases when multiple observers are interested in notifications of a newly available sensor reading, an event listener can be added on a single Sensor instance instead of +creating multiple instances of the same sensor type and using simple onreading event handler.

                              -

                              Conversely, multiple Sensors of the same sensor type can be created when they +

                              Conversely, multiple Sensors of the same sensor type can be created when they are intended to be used with different settings, such as: requested sampling frequency, accuracy or other settings defined in extension specifications.

                              9.6. Definition Requirements

                              The following definitions must be specified for -each sensor type in extension specifications:

                              +each sensor type in extension specifications:

                              An extension specification may specify the following definitions -for each sensor types:

                              +for each sensor types:

                              9.7. Extending the Permission API

                              -

                              An implementation of the Sensor interface for each sensor type must protect its reading by associated PermissionName or PermissionDescriptor. -A Low-level sensor may use its interface name as a PermissionName, +

                              An implementation of the Sensor interface for each sensor type must protect its reading by associated permission name or PermissionDescriptor. +A Low-level sensor may use its interface name as a permission name, for instance, "gyroscope" or "accelerometer". Fusion sensors must request permission to access each of the sensors that are used as a source of fusion.

                              Even though, it might be difficult to reconstruct low-level sensor readings from @@ -3014,17 +3020,17 @@

                              9.8. Extending the Feature Policy API

                              -

                              An implementation of the Sensor interface for each sensor type has one +

                              An implementation of the Sensor interface for each sensor type has one (if sensor fusion is not performed) or several policy-controlled features that control whether or not this implementation can be used in a document.

                              The features' default allowlist is ["self"].

                              -

                              Note: The default allowlist of ["self"] allows Sensor interface +

                              Note: The default allowlist of ["self"] allows Sensor interface implementation usage in same-origin nested frames but prevents third-party content from sensor readings access.

                              -

                              The sensor feature names set must contain feature names of +

                              The sensor feature names set must contain feature names of every associated feature.

                              -

                              A Low-level sensor may use its interface name as a feature name, +

                              A Low-level sensor may use its interface name as a feature name, for instance, "gyroscope" or "accelerometer". Unless the extension specification tells -otherwise, the sensor feature names matches the same type-associated sensor permission names.

                              +otherwise, the sensor feature names matches the same type-associated sensor permission names.

                              The accelerometer feature is selectively enabled for third-party origin by adding allow attribute to the frame container element:
                              <iframe src="https://third-party.com" allow="accelerometer"/></iframe>
                              @@ -3160,7 +3166,7 @@ 

                              This is an example of an informative example.

                              -

                              Because this document doesn’t itself define APIs for specific sensor typesthat is the role of extensions to this specification—all examples are inevitably (wishful) fabrications. +

                              Because this document doesn’t itself define APIs for specific sensor typesthat is the role of extensions to this specification—all examples are inevitably (wishful) fabrications. Although all of the sensors used a examples would be great candidates for building atop the Generic Sensor API, their inclusion in this document does not imply that the relevant Working Groups @@ -3440,6 +3446,7 @@

                              in parallel
                            1. nested browsing context
                            2. origin +
                            3. responsible document
                            4. same origin-domain
                            5. spin the event loop
                            6. task @@ -3475,8 +3482,9 @@

                              PermissionDescriptor
                            7. PermissionName
                            8. new information about the user's intent +
                            9. permission name
                            10. permission revocation algorithm -
                            11. permission state +
                            12. permission state
                            13. request permission to use
                            14. @@ -3703,22 +3711,22 @@

                              I
                            15. 5.4. Reading change threshold
                            16. 5.5. Sampling Frequency and Reporting Frequency
                            17. 5.6. Conditions to expose sensor readings -
                            18. 6.2. Sensor (2) (3) (4) (5) (6) (7) (8) (9) -
                            19. 7.1. The Sensor Interface (2) (3) -
                            20. 7.1.1. Sensor lifecycle -
                            21. 7.1.3. Sensor internal slots -
                            22. 8.3. Connect to sensor (2) (3) -
                            23. 8.4. Activate a sensor object -
                            24. 8.5. Deactivate a sensor object -
                            25. 8.6. Revoke sensor permission -
                            26. 8.7. Set sensor settings -
                            27. 8.8. Update latest reading -
                            28. 8.9. Find the reporting frequency of a sensor object -
                            29. 8.12. Notify activated state -
                            30. 8.14. Get value from latest reading -
                            31. 8.15. Request sensor access -
                            32. 9.2. Naming (2) (3) -
                            33. 9.6. Definition Requirements +
                            34. 6.2. Sensor (2) (3) (4) (5) (6) (7) (8) +
                            35. 7.1. The Sensor Interface (2) (3) +
                            36. 7.1.1. Sensor lifecycle +
                            37. 7.1.3. Sensor internal slots +
                            38. 8.3. Connect to sensor (2) (3) +
                            39. 8.4. Activate a sensor object +
                            40. 8.5. Deactivate a sensor object +
                            41. 8.6. Revoke sensor permission +
                            42. 8.7. Set sensor settings +
                            43. 8.8. Update latest reading +
                            44. 8.9. Find the reporting frequency of a sensor object +
                            45. 8.12. Notify activated state +
                            46. 8.14. Get value from latest reading +
                            47. 8.15. Request sensor access +
                            48. 9.2. Naming (2) (3) +
                            49. 9.6. Definition Requirements