I'm requesting a TAG review of the WebXR XRSession::enabledFeatures attribute.
This is a modification to the existing WebXR API since CR (the only one to date) to allow exposing “enabledFeatures” from the XRSession object. This allows developers to detect what features they requested actually end up enabled on the session. While most features have some ability to be detected, some features may have similar failure modes for not being enabled and being enabled but not currently having data to supply (many reference spaces for example). Some features (such as the newly proposed front-facing camera), don’t have any observable effects or any other way for us to signal to developers that it was enabled. While developers can be sure that if they received an XRSession they were granted all of their “requiredFeatures”, they cannot be sure of the state of their “optionalFeatures”.
Tests: url (Note that tests for this feature have not been written yet)
User research: N/a
Security and Privacy self-review²: No major changes from existing WebXR Security and Privacy review; most of the data should be available already during the course of normal operation, so this only provides an easier way to access data that is mostly already exposed/observable, and is only available once an XRSession has been granted.
GitHub repo (if you prefer feedback filed there): url
Primary contacts (and their relationship to the specification):
Brandon Jones (@toji), Google, Editor
Manish Goregaokar, (@manishearth), Google, Editor
Rik Cabanier (@cabanier), Meta, Editor
Ada Rose Cannon (@AdaRoseCannon), Apple, Chair
Chris Wilson (@cwilso), Google, Chair
Ayşegül Yönet (@yonet), Microsoft, Chair
Organization(s)/project(s) driving the specification: Immersive Web Working Group
Key pieces of existing multi-stakeholder review or discussion of this specification:
Wotcher TAG!
I'm requesting a TAG review of the WebXR XRSession::enabledFeatures attribute.
This is a modification to the existing WebXR API since CR (the only one to date) to allow exposing “enabledFeatures” from the XRSession object. This allows developers to detect what features they requested actually end up enabled on the session. While most features have some ability to be detected, some features may have similar failure modes for not being enabled and being enabled but not currently having data to supply (many reference spaces for example). Some features (such as the newly proposed front-facing camera), don’t have any observable effects or any other way for us to signal to developers that it was enabled. While developers can be sure that if they received an XRSession they were granted all of their “requiredFeatures”, they cannot be sure of the state of their “optionalFeatures”.
Further details:
You should also know that... N/a
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback