-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose a way to query a session about the supported features #952
Comments
I think I'm missing how what I'm describing is solved by PR #900 - can you share a code snippet that would allow the application to know whether for example My understanding is that it'd require us to expose XRSession's (or XRDevice's, after PR lands) list of enabled features through the Web IDL directly or indirectly and that does not seem to be happening anywhere. xr.requestSession('immersive-ar', {optionalFeatures: ['local-floor']}).then((session) => {
// How to check if local-floor is supported, w/o calling
// session.requestReferenceSpace('local-floor)?
}); |
navigator.permissions.query({mode: "immersive-ar", requiredFeatures: "local-floor", optionalFeatures: "hit-test"}).then((status) => console.log(status.granted))
|
The point of those issues and that PR is so that we can leverage all the existing machinery that the Permissions API has for this. |
@Manishearth wrote:
Are all the feature names in a global permission namespace, or is there an "xr" missing in this example? https://github.com/immersive-web/webxr/pull/900/files refers to the "xr" permission, but I'm not sure how that name is intended to be used. |
Yeah, there's a |
Currently, when UAs resolve a
requestSession
request that had someoptionalFeatures
set, there is no easy way to query which of those features are supported on the newly created session. This is currently only relevant for different reference spaces, but as we add more optional features, the pattern of trying to use the optional feature and handling a failure in case it's not supported is not necessarily ideal. For example, if the application wants to know in advance if a feature is supported, it might have to try and use the feature in some artificial way, even though the feature might be really needed at later stages of the experience.I think it would be helpful to expose the information about the optional features, for example by adding an attribute on
XRSession
. Something like asequence<any> supportedOptionalFeatures
that is a subset of entries passed viaXRSessionInit.optionalFeatures
would be one way to solve this.Additional context: immersive-web/hit-test#68.
The text was updated successfully, but these errors were encountered: