Merge pull request #3 from immersive-web/main

Update with main repo

index.bs

@@ -232,7 +232,7 @@ An <dfn for="">XR device</dfn> is a physical unit of hardware that can present i
 
 An [=/XR device=] has a <dfn>list of supported modes</dfn> (a [=/list=] of [=/strings=]) that [=list/contains=] the enumeration values of {{XRSessionMode}} that the [=/XR device=] supports.
 
-Each [=/XR device=] has a <dfn for="XR device">list of enabled features</dfn> 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 <dfn for="XR device">set of granted features</dfn> 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 <dfn for="">list of immersive XR devices</dfn> (a [=/list=] of [=/XR device=]), which MUST be initially an empty [=/list=].
 
@@ -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:
             <dl class="switch">
               : If |immersive| is `true`:
@@ -642,11 +643,14 @@ Each {{XRSession}} has a <dfn for="XRSession">mode</dfn>, which is one of the va
 
 Each {{XRSession}} has an <dfn for=XRSession>animation frame</dfn>, 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 <dfn for=XRSession>set of granted features</dfn>, which is a [=/set=] of {{DOMString}}s corresponding the the [=feature descriptors=] that have been granted to the {{XRSession}}.
+
 <div class="algorithm" data-algorithm="initialize-session">
 
-To <dfn>initialize the session</dfn>, given |session|, |mode|, and |device|, the user agent MUST run the following steps:
+To <dfn>initialize the session</dfn>, 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
 <div class="algorithm" data-algorithm="reference-space-supported">
 To check if a <dfn>reference space is supported</dfn> 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/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`.
@@ -2453,7 +2457,7 @@ In some environments a page may be presented as an application, installed with t
 
 ### Implicit and Explicit consent ### {#user-consent}
 
-<dfn>Implicit consent</dfn> 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.
+<dfn>Implicit consent</dfn> 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.
 
 <dfn>Explicit consent</dfn> 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.
 
@@ -2761,7 +2765,7 @@ To <dfn lt="request the xr permission">request the "xr" permission</dfn> 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 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.
@@ -2799,11 +2803,12 @@ To <dfn>resolve the requested features</dfn> 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/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 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 +2818,7 @@ To <dfn>resolve the requested features</dfn> 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 +2829,7 @@ To <dfn>resolve the requested features</dfn> 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|)`
 

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 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), 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`.
 
@@ -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.