From 9d8cdc806cb1f5c9c32e287b89fb865adec86867 Mon Sep 17 00:00:00 2001 From: Rik Cabanier Date: Mon, 29 Mar 2021 10:55:37 -0700 Subject: [PATCH 1/7] enhance examples of implicit user intent --- index.bs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.bs b/index.bs index ac43c88f..32f56bbd 100644 --- a/index.bs +++ b/index.bs @@ -2453,7 +2453,7 @@ In some environments a page may be presented as an application, installed with t ### Implicit and Explicit consent ### {#user-consent} -Implicit consent is when the user agent makes a judgement on the consent of a user without explicitly asking for it, for example, based on the install status of a web application or frequency and recency of visits. Given the sensitivity of XR data, caution is strongly advised when relying on implicit signals. +Implicit consent is when the user agent makes a judgement on the consent of a user without explicitly asking for it, for example, based on the install status of a web application, frequency and recency of visits or a user agent defined action where the user clearly signals intent that they want to enter an immersive experience. Given the sensitivity of XR data, caution is strongly advised when relying on implicit signals. Explicit consent is when the user agent makes a judgement on the consent of a user based on having explicitly asked for it. When gathering [=explicit consent=], user agents present an explanation of what is being requested and provide users the option to decline. Requests for user consent can be presented in many visual forms based on the features being protected and user agent choice. Install status of a web application MAY count as a signal of [=explicit consent=] provided some form of [=explicit consent=] is requested at install time. From c6b889d8d973b536f25df68fed7839ec46b49bb6 Mon Sep 17 00:00:00 2001 From: Manish Goregaokar Date: Tue, 30 Mar 2021 11:58:51 -0700 Subject: [PATCH 2/7] permissions: Only inherit granted features that are explicitly requested --- index.bs | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/index.bs b/index.bs index 32f56bbd..d8212367 100644 --- a/index.bs +++ b/index.bs @@ -2799,11 +2799,12 @@ To resolve the requested features given |requiredFeatures| and |optio 1. Let |consentRequired| be an empty [=/list=] of {{DOMString}}. 1. Let |consentOptional| be an empty [=/list=] of {{DOMString}}. + 1. Let |granted| be an empty [=/list=] of {{DOMString}}. 1. Let |device| be the result of [=obtain the current device|obtaining the current device=] for |mode|, |requiredFeatures|, and |optionalFeatures|. - 1. Let |granted| be a [=/list=] of {{DOMString}} initialized to |device|'s [=XR device/list of enabled features=] for |mode|. + 1. Let |previouslyEnabled| be |device|'s [=XR device/list of enabled features=] for |mode|. 1. If |device| is `null` or |device|'s [=list of supported modes=] does not [=list/contain=] |mode|, run the following steps: 1. Return the [=tuple=] (|consentRequired|, |consentOptional|, |granted|) - 1. Add every [=feature descriptor=] in the [=default features=] table associated with |mode| to the indicated feature list if it is not already present. + 1. Add every [=feature descriptor=] in the [=default features=] table associated with |mode| to |granted| if it is not already present. 1. For each |feature| in |requiredFeatures| perform the following steps: 1. If the |feature| is `null`, [=continue=] to the next entry. 1. If |feature| is not a valid [=feature descriptor=], perform the following steps: @@ -2813,7 +2814,7 @@ To resolve the requested features given |requiredFeatures| and |optio 1. If |feature| is already in |granted|, continue to the next entry. 1. If the requesting document's [=origin=] is not allowed to use any [[#permissions-policy|permissions policy]] required by |feature| as indicated by the [=feature requirements=] table, return `null`. 1. If |session|'s [=XRSession/XR device=] is not [=capable of supporting=] the functionality described by |feature| or the user agent has otherwise determined to reject the feature, return `null`. - 1. If the functionality described by |feature| requires [=explicit consent=], append it to |consentRequired|. + 1. If the functionality described by |feature| requires [=explicit consent=] and |feature| is not in |previouslyEnabled|, append it to |consentRequired|. 1. Else append |feature| to |granted|. 1. For each |feature| in |optionalFeatures| perform the following steps: 1. If the |feature| is `null`, [=continue=] to the next entry. @@ -2824,7 +2825,7 @@ To resolve the requested features given |requiredFeatures| and |optio 1. If |feature| is already in |granted|, continue to the next entry. 1. If the requesting document's origin is not allowed to use any [[#permissions-policy|permissions policy]] required by |feature| as indicated by the [=feature requirements=] table, continue to the next entry. 1. If |session|'s [=XRSession/XR device=] is not [=capable of supporting=] the functionality described by |feature| or the user agent has otherwise determined to reject the feature, continue to the next entry. - 1. If the functionality described by |feature| requires [=explicit consent=], append it to |consentOptional|. + 1. If the functionality described by |feature| requires [=explicit consent=] and |feature| is not in |previouslyEnabled|, append it to |consentOptional|. 1. Else append |feature| to |granted|. 1. Return the [=tuple=] `(|consentRequired|, |consentOptional|, |granted|)` From 7886f91d9832eb90449a3fb466162f8a048e64e1 Mon Sep 17 00:00:00 2001 From: Manish Goregaokar Date: Tue, 30 Mar 2021 12:00:17 -0700 Subject: [PATCH 3/7] Use set instead of list for device's list of enabled features --- index.bs | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/index.bs b/index.bs index d8212367..ca372fdf 100644 --- a/index.bs +++ b/index.bs @@ -232,7 +232,7 @@ An XR device is a physical unit of hardware that can present i An [=/XR device=] has a list of supported modes (a [=/list=] of [=/strings=]) that [=list/contains=] the enumeration values of {{XRSessionMode}} that the [=/XR device=] supports. -Each [=/XR device=] has a list of enabled features for each {{XRSessionMode}} in its [=list of supported modes=], which is a [=/list=] of [=feature descriptors=] which MUST be initially an empty [=/list=]. +Each [=/XR device=] has a set of enabled features for each {{XRSessionMode}} in its [=list of supported modes=], which is a [=/set=] of [=feature descriptors=] which MUST be initially an empty [=/set=]. The user-agent has a list of immersive XR devices (a [=/list=] of [=/XR device=]), which MUST be initially an empty [=/list=]. @@ -1282,7 +1282,7 @@ When an {{XRReferenceSpace}} is requested with {{XRReferenceSpaceType}} |type| f
To check if a reference space is supported for a given reference space type |type| and {{XRSession}} |session|, run the following steps: - 1. If |type| is not [=list/contain|contained=] in |session|'s [=XRSession/XR device=]'s [=XR device/list of enabled features=] for [=XRSession/mode=] return `false`. + 1. If |type| is not [=list/contain|contained=] in |session|'s [=XRSession/XR device=]'s [=XR device/set of enabled features=] for [=XRSession/mode=] return `false`. 1. If |type| is {{viewer}}, return `true`. 1. If |type| is {{local}} or {{local-floor}}, and |session| is an [=immersive session=], return `true`. 1. If |type| is {{local}} or {{local-floor}}, and the [=XRSession/XR device=] supports reporting orientation data, return `true`. @@ -2761,7 +2761,7 @@ To request the "xr" permission with an 1. If a clear signal of [=user intent=] to enable |feature| has not been determined, continue to the next entry. 1. If |feature| is not in |granted|, append |feature| to |granted|. 1. Set |status|'s {{XRPermissionStatus/granted}} to |granted|. - 1. Set |device|'s [=list of enabled features=] for |mode| to |granted|. + 1. Add all elements of |granted| to |device|'s [=set of enabled features=] for |mode|. 1. Set |status|'s {{PermissionStatus/state}} to {{PermissionState/"granted"}}. Note: The user agent has the freedom to batch up permissions prompts for all requested features when gauging if there is a clear signal of [=user intent=], but it is also allowed to show them one at a time. @@ -2801,7 +2801,7 @@ To resolve the requested features given |requiredFeatures| and |optio 1. Let |consentOptional| be an empty [=/list=] of {{DOMString}}. 1. Let |granted| be an empty [=/list=] of {{DOMString}}. 1. Let |device| be the result of [=obtain the current device|obtaining the current device=] for |mode|, |requiredFeatures|, and |optionalFeatures|. - 1. Let |previouslyEnabled| be |device|'s [=XR device/list of enabled features=] for |mode|. + 1. Let |previouslyEnabled| be |device|'s [=XR device/set of enabled features=] for |mode|. 1. If |device| is `null` or |device|'s [=list of supported modes=] does not [=list/contain=] |mode|, run the following steps: 1. Return the [=tuple=] (|consentRequired|, |consentOptional|, |granted|) 1. Add every [=feature descriptor=] in the [=default features=] table associated with |mode| to |granted| if it is not already present. From 502defedf433efdbec7304a37faead4d8939799c Mon Sep 17 00:00:00 2001 From: Manish Goregaokar Date: Tue, 30 Mar 2021 12:06:05 -0700 Subject: [PATCH 4/7] Add set of granted features to XRSession --- index.bs | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index ca372fdf..d0220a77 100644 --- a/index.bs +++ b/index.bs @@ -415,8 +415,9 @@ When this method is invoked, the user agent MUST run the following steps: 1. [=Reject=] |promise| with a "{{NotSupportedError}}" {{DOMException}}. 1. If |immersive| is `true`, set [=pending immersive session=] to `false`. 1. Abort these steps. + 1. Let |granted| be a [=/set=] obtained from |status|' {{XRPermissionStatus/granted}}. 1. Let |session| be a [=new=] {{XRSession}} object in the [=relevant realm=] of this {{XRSystem}}. - 1. [=Initialize the session=] with |session|, |mode|, and |device|. + 1. [=Initialize the session=] with |session|, |mode|, |granted|, and |device|. 1. Potentially set the [=active immersive session=] as follows:
: If |immersive| is `true`: @@ -642,11 +643,14 @@ Each {{XRSession}} has a mode, which is one of the va Each {{XRSession}} has an animation frame, which is an {{XRFrame}} initialized with [=XRFrame/active=] set to `false`, [=XRFrame/animationFrame=] set to `true`, and {{XRFrame/session}} set to the {{XRSession}}. +Each {{XRSession}} has a set of granted features, which is a [=/set=] of {{DOMString}}s corresponding the the [=feature descriptors=] that have been granted to the {{XRSession}}. +
-To initialize the session, given |session|, |mode|, and |device|, the user agent MUST run the following steps: +To initialize the session, given |session|, |mode|, |granted|, and |device|, the user agent MUST run the following steps: 1. Set |session|'s [=XRSession/mode=] to |mode|. 1. Set |session|'s [=XRSession/XR device=] to |device|. + 1. Set |session|'s [=XRSession/set of granted features=] to |granted|. 1. [=Initialize the render state=]. 1. If no other features of the user agent have done so already, perform the necessary platform-specific steps to initialize the device's tracking and rendering capabilities, including showing any necessary instructions to the user. @@ -1282,7 +1286,7 @@ When an {{XRReferenceSpace}} is requested with {{XRReferenceSpaceType}} |type| f
To check if a reference space is supported for a given reference space type |type| and {{XRSession}} |session|, run the following steps: - 1. If |type| is not [=list/contain|contained=] in |session|'s [=XRSession/XR device=]'s [=XR device/set of enabled features=] for [=XRSession/mode=] return `false`. + 1. If |type| is not [=list/contain|contained=] in |session|'s [=XRSession/set of granted features=]'s return `false`. 1. If |type| is {{viewer}}, return `true`. 1. If |type| is {{local}} or {{local-floor}}, and |session| is an [=immersive session=], return `true`. 1. If |type| is {{local}} or {{local-floor}}, and the [=XRSession/XR device=] supports reporting orientation data, return `true`. From b6ab53fac50f7875c88e49dad090da6dc9f4e44c Mon Sep 17 00:00:00 2001 From: Manish Goregaokar Date: Tue, 30 Mar 2021 12:06:32 -0700 Subject: [PATCH 5/7] set of enabled features -> set of granted features --- index.bs | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index d0220a77..fbb17e5e 100644 --- a/index.bs +++ b/index.bs @@ -232,7 +232,7 @@ An XR device is a physical unit of hardware that can present i An [=/XR device=] has a list of supported modes (a [=/list=] of [=/strings=]) that [=list/contains=] the enumeration values of {{XRSessionMode}} that the [=/XR device=] supports. -Each [=/XR device=] has a set of enabled features for each {{XRSessionMode}} in its [=list of supported modes=], which is a [=/set=] of [=feature descriptors=] which MUST be initially an empty [=/set=]. +Each [=/XR device=] has a set of granted features for each {{XRSessionMode}} in its [=list of supported modes=], which is a [=/set=] of [=feature descriptors=] which MUST be initially an empty [=/set=]. The user-agent has a list of immersive XR devices (a [=/list=] of [=/XR device=]), which MUST be initially an empty [=/list=]. @@ -2765,7 +2765,7 @@ To request the "xr" permission with an 1. If a clear signal of [=user intent=] to enable |feature| has not been determined, continue to the next entry. 1. If |feature| is not in |granted|, append |feature| to |granted|. 1. Set |status|'s {{XRPermissionStatus/granted}} to |granted|. - 1. Add all elements of |granted| to |device|'s [=set of enabled features=] for |mode|. + 1. Add all elements of |granted| to |device|'s [=set of granted features=] for |mode|. 1. Set |status|'s {{PermissionStatus/state}} to {{PermissionState/"granted"}}. Note: The user agent has the freedom to batch up permissions prompts for all requested features when gauging if there is a clear signal of [=user intent=], but it is also allowed to show them one at a time. @@ -2805,7 +2805,7 @@ To resolve the requested features given |requiredFeatures| and |optio 1. Let |consentOptional| be an empty [=/list=] of {{DOMString}}. 1. Let |granted| be an empty [=/list=] of {{DOMString}}. 1. Let |device| be the result of [=obtain the current device|obtaining the current device=] for |mode|, |requiredFeatures|, and |optionalFeatures|. - 1. Let |previouslyEnabled| be |device|'s [=XR device/set of enabled features=] for |mode|. + 1. Let |previouslyEnabled| be |device|'s [=XR device/set of granted features=] for |mode|. 1. If |device| is `null` or |device|'s [=list of supported modes=] does not [=list/contain=] |mode|, run the following steps: 1. Return the [=tuple=] (|consentRequired|, |consentOptional|, |granted|) 1. Add every [=feature descriptor=] in the [=default features=] table associated with |mode| to |granted| if it is not already present. From 0e68e0927f745084db3eeec79059c37049a923cd Mon Sep 17 00:00:00 2001 From: Rashid Date: Tue, 12 Jan 2021 16:06:27 -0600 Subject: [PATCH 6/7] Fixed a few typos and inconsistencies --- spatial-tracking-explainer.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spatial-tracking-explainer.md b/spatial-tracking-explainer.md index 869d56ef..6b044d96 100644 --- a/spatial-tracking-explainer.md +++ b/spatial-tracking-explainer.md @@ -45,7 +45,7 @@ The wide range of hardware form factors makes it impractical and unscalable to e There are several types of reference spaces: `viewer`, `local`, `local-floor`, `bounded-floor`, and `unbounded`, each mapping to a type of XR experience an app may wish to build. A _bounded_ experience (`bounded-floor`) is one in which the user will move around their physical environment to fully interact, but will not need to travel beyond a fixed boundary defined by the XR hardware. An _unbounded_ experience (`unbounded`) is one in which a user is able to freely move around their physical environment and travel significant distances. A _local_ experience is one which does not require the user to move around in space, and may be either a "seated" (`local`) or "standing" (`local-floor`) experience. Finally, the `viewer` reference space can be used for experiences that function without any tracking (such as those that use click-and-drag controls to look around) or in conjunction with another reference space to track head-locked objects. Examples of each of these types of experiences can be found in the detailed sections below. -It is worth noting that not all experiences will work on all XR hardware and not all XR hardware will support all experiences (see [Appendix A: XRReferenceSpace Availability](#xrreferencespace-availability)). For example, it is not possible to build a experience which requires the user to walk around on a device like a GearVR. In the spirit of [progressive enhancement](https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement), it is strongly recommended that developers select the least capable `XRReferenceSpace` that suffices for the experience they are building. Requesting a more capable reference space will artificially restrict the set of XR devices their experience will otherwise be viewable from. +It is worth noting that not all experiences will work on all XR hardware and not all XR hardware will support all experiences (see [Appendix A: XRReferenceSpace Availability](#xrreferencespace-availability)). For example, it's impossible to build an experience which requires the user to walk around on a device like GearVR. In the spirit of [progressive enhancement](https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement), it's strongly recommended that developers select the least capable `XRReferenceSpace` that suffices for the experience they are building. Requesting a more capable reference space will artificially restrict the set of XR devices their experience will otherwise be viewable from. ### Bounded reference space A _bounded_ experience is one in which a user moves around their physical environment to fully interact, but will not need to travel beyond a pre-established boundary. A bounded experience is similar to an unbounded experience in that both rely on XR hardware capable of tracking a users' locomotion. However, bounded experiences are explicitly focused on nearby content which allows them to target XR hardware that requires a pre-configured play area as well as XR hardware able to track location freely. @@ -228,7 +228,7 @@ The `viewer` reference space is also useful when the developer wants to compare ``` ## Spatial relationships -One of the core features of any XR platform is its ability to track spatial relationships. Tracking the position and orientation, referred to together as a "pose", of the viewer is perhaps the simplest example, but many other XR platform features, such as hit testing or anchors, are rooted in understanding the space the XR system is operating in. In WebXR any feature that tracks spatial relationships is built on top of the `XRSpace` interface. Each `XRSpace` represents something being tracked by the XR system, such as an `XRReferenceSpace`, and each has a "native origin" that represents it's position and orientation in the XR tracking system. It is only possible to know the location of one `XRSpace` relative to another `XRSpace` on a frame-by-frame basis. +One of the core features of any XR platform is its ability to track spatial relationships. Tracking the position and orientation, referred to together as a "pose", of the viewer is perhaps the simplest example, but many other XR platform features, such as hit testing or anchors, are rooted in understanding the space the XR system is operating in. In WebXR any feature that tracks spatial relationships is built on top of the `XRSpace` interface. Each `XRSpace` represents something being tracked by the XR system, such as an `XRReferenceSpace`, and each has a "native origin" that represents its position and orientation in the XR tracking system. It is only possible to know the location of one `XRSpace` relative to another `XRSpace` on a frame-by-frame basis. ### Rigid Transforms Coordinates accepted as input or provided as output from WebXR are always expressed within a specific `XRSpace` chosen by the developer. When working with real-world spaces, it is important to be able to express transforms exclusively in terms of position and orientation. In WebXR this is done through the `XRRigidTransform` which contains a `position` vector and an `orientation` quaternion. When interpreting an `XRRigidTransform` the `orientation` is applied prior to the `position`. This means that, for example, a transform that indicates a quarter rotation to the right and a 1-meter translation along -Z would place a transformed object at `[0, 0, -1]` facing to the right. `XRRigidTransform`s also have a `matrix` attribute that reports the same transform as a 4×4 matrix when needed. By definition, the matrix of a rigid transform cannot contain scale or skew. From cf3c251a701dd39a4a288b6d20939d4ea84e55bd Mon Sep 17 00:00:00 2001 From: Rashid Date: Fri, 16 Apr 2021 15:59:01 -0500 Subject: [PATCH 7/7] editing for clarity --- spatial-tracking-explainer.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spatial-tracking-explainer.md b/spatial-tracking-explainer.md index 6b044d96..e048bd52 100644 --- a/spatial-tracking-explainer.md +++ b/spatial-tracking-explainer.md @@ -45,10 +45,10 @@ The wide range of hardware form factors makes it impractical and unscalable to e There are several types of reference spaces: `viewer`, `local`, `local-floor`, `bounded-floor`, and `unbounded`, each mapping to a type of XR experience an app may wish to build. A _bounded_ experience (`bounded-floor`) is one in which the user will move around their physical environment to fully interact, but will not need to travel beyond a fixed boundary defined by the XR hardware. An _unbounded_ experience (`unbounded`) is one in which a user is able to freely move around their physical environment and travel significant distances. A _local_ experience is one which does not require the user to move around in space, and may be either a "seated" (`local`) or "standing" (`local-floor`) experience. Finally, the `viewer` reference space can be used for experiences that function without any tracking (such as those that use click-and-drag controls to look around) or in conjunction with another reference space to track head-locked objects. Examples of each of these types of experiences can be found in the detailed sections below. -It is worth noting that not all experiences will work on all XR hardware and not all XR hardware will support all experiences (see [Appendix A: XRReferenceSpace Availability](#xrreferencespace-availability)). For example, it's impossible to build an experience which requires the user to walk around on a device like GearVR. In the spirit of [progressive enhancement](https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement), it's strongly recommended that developers select the least capable `XRReferenceSpace` that suffices for the experience they are building. Requesting a more capable reference space will artificially restrict the set of XR devices their experience will otherwise be viewable from. +It is worth noting that not all experiences will work on all XR hardware and not all XR hardware will support all experiences (see [Appendix A: XRReferenceSpace Availability](#xrreferencespace-availability)). For example, it's impossible to build an experience which requires the user to walk around on a device like GearVR. In the spirit of [progressive enhancement](https://developer.mozilla.org/en-US/docs/Glossary/Progressive_Enhancement), developers are advised to select the least capable `XRReferenceSpace` that suffices for the experience they are building. Requesting a more capable reference space will artificially restrict the set of XR devices that could otherwise handle the experience. ### Bounded reference space -A _bounded_ experience is one in which a user moves around their physical environment to fully interact, but will not need to travel beyond a pre-established boundary. A bounded experience is similar to an unbounded experience in that both rely on XR hardware capable of tracking a users' locomotion. However, bounded experiences are explicitly focused on nearby content which allows them to target XR hardware that requires a pre-configured play area as well as XR hardware able to track location freely. +In a _bounded_ experience, a user moves and fully interacts with their physical environment, but doesn't need to travel beyond a pre-established boundary. Both bounded and unbounded experiences rely on XR hardware capable of tracking a user's locomotion. However, bounded experiences explicitly focus on nearby content which allows them to target both XR hardware that requires a pre-configured play area and the ones that are able to track location freely. Bounded experiences use an `XRReferenceSpaceType` of `bounded-floor`.