You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes some changes to how we pick inline devices that make the spec line up more closely with the group's intent for when inline sessions are allowed to expose tracking data, as well as add a bit of non-normative text to more clearly explain the purpose of the default inline session that can be accessed without first gaining user consent.
The reason will be displayed to describe this comment to others. Learn more.
What about input events in the case when the XR device being used by the inline session is not the inline XR device (i.e. someone is in a 2D browser on a headset)? Should we file this separately?
I'm not sure I follow, @Manishearth? You mean 2D page inputs generated by an XR controller? The UA should be handling the management of those input into pointer events already, and those pointer events should be the only thing exposed. From this PR:
MUST NOT report [=XR input source=]s or events other than those created by pointer events.
Yes, the case that the inline XR device that gets selected is not the default inline XR device. The spec is structured such that e.g. if you're in a 2D browser on a device, the inline XR device that gets selected is the same as the immersive one, so you can expose head poses.
Yes, the case that the inline XR device that gets selected is not the default inline XR device. The spec is structured such that e.g. if you're in a 2D browser on a device, the inline XR device that gets selected is the same as the immersive one, so you can expose head poses.
I think that should be addressed by the change to obtaining the current device, which now states that if the features arrays are empty you always get the default device.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
/fixes #984
This makes some changes to how we pick inline devices that make the spec line up more closely with the group's intent for when inline sessions are allowed to expose tracking data, as well as add a bit of non-normative text to more clearly explain the purpose of the default inline session that can be accessed without first gaining user consent.
CC: @pes10k