beforexrselect confusion

[alice]

Coming here from the TAG review thread, as we are looking at this at our virtual face-to-face.

The explainer mentions

"WebXR's input events ("selectstart", "selectend", and "select") potentially duplicate DOM events"

I wasn't clear from the explainer on why this is the case. Could you give a fuller example, demonstrating when beforexrselect would solve such a problem?

Also, the previous paragraph reads,

If a WebXR application uses a DOM overlay in conjunction with XR input, it is possible that a user action could be interpreted as both an interaction with a DOM element and a 3D input to the XR application, for example if the user touches an onscreen button, or uses a controller's primary button while pointing at the DOM overlay.

Does this imply that the same is true for, e.g., click? How would I specify where the click event should be handled?

[klausw]

I've added a more detailed explanation in 51e7273#diff-817a23c792520ce222813d3eff70d031 , including examples.

Does this imply that the same is true for, e.g., click? How would I specify where the click event should be handled?

In general yes. If you want the DOM to handle the click exclusively, assign a DOM click event handler and call preventDefault on the beforexrselect event. If you want it to be treated as XR input exclusively, don't set any DOM event handlers. If you have a click event handler but don't preventDefault the beforexrselect, you get both.

In practice it's usually convenient to set the beforexrselect handler on a container element as opposed to each button/input individually. This also makes it possible to control the behavior of third-party UI libraries such as dat.gui that aren't aware of beforexrselect.