Clarify when tracking/input data is exposed via inline devices#985
Conversation
Manishearth
left a comment
There was a problem hiding this comment.
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:
Is there a case I'm overlooking here? |
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. |
Do you know of a UA that implements this? |
|
I think that should be addressed by the change to |
/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