Add startSqueezing/endSqueezing/simulateSqueeze

[Artyom17]

To match the 'select' event testing, why don't we add the startSqueezing/endSqueezing/simulateSqueeze methods, as well as squeezingStarted, squeezingClicked states?

[Manishearth]

Yeah, we should add these

[alcooper91]

I'm a little hesitant on this. The select button is required on an XRInputSource, and as such we didn't define the select button in FakeXrButtonType. However, the grip does exist in FakeXrButtonType, so these would really just be a convenience wrapper around updateButtonState

[Manishearth]

It's possible for an XR device to support squeeze but not a gamepad (we're doing this for hands on Hololens)

[alcooper91]

updateButtonState doesn't require gamepad though?

It still feels wrong to expose two ways of doing the same thing

[Manishearth]

Oh, I see. Yeah.

However: I don't think the updateButtonState can simulate cancellation; which is possible for both select and squeeze events (and leads to a selectend event not paired with a select event). Not a big deal, but something to think about.

[alcooper91]

I don't think our mechanism for select can simulate cancellation right now?

we have startSelection/endSelection and then simulateSelect, which from the explainer is a subframe select (so guaranteed to send the select on the next frame, which I think calling startSelection/endSelection may not guarantee)

[alcooper91]

One compromise here could be to allow the webxr_util class to polyfill in such a helper. (at least for the start/stop)

[Manishearth]

Hmm, we perhaps should change the APIs then to startSelect/endSelect/cancelSelect?

That maps more cleanly to the "start, end, cancel" framing that's in the spec: https://immersive-web.github.io/webxr/#primary-squeeze-action

IMO this API should hook directly into such spec algorithms (which are triggered by the device) as much as possible. Basically, wherever the core spec ends up in a "obtain this data from the device" or "when the device decides to do X", we should have an API for that.

[Manishearth]

In the current test API this hooks more directly into the user side rather than the device side.

[Manishearth]

Also, if we're doing this, it might be worth having just startSelect/endSelect/cancelSelect with a squeeze optional boolean argument

[alcooper91]

That kind of feels like overriding the existing method for the sake of not adding a new one, in a way that feels neither scalable nor intuitive IMO

[Manishearth]

That's fair. We can also add a new one then.

[alcooper91]

If we're okay with removing one (that we maybe keep polyfilled in) We could also do something like

startPrimaryAction(FakeXrPrimaryAction action)
stopPrimaryAction(FakeXrPrimaryAction action)

where currently

enum FakeXrPrimaryAction {
  "select",
  "squeeze",
}

[alcooper91]

Though "squeeze" would still be possible via updateButtonState, unless we wanted to explicitly disallow that.

[Artyom17]

So, should the implementation of updateButtonState check, that the button[1] has been changed, therefore fire the squeeze event? Currently, it just updates the gamepad object (in Chromium implementation) and this doesn't and wouldn't cause the squeeze events firing.

Also, should the updating button[0] cause select events to fire somehow?

EDIT: talked to Alex offline, seems like it is just an issue in Google's implementation of updateButtonState and it indeed should fire select/squeeze events....