This is a regression from the polyfill which does report touch start/end and can be used to handle long press as a distinct action.

Also, for consistency, we should impelment equivalent behavior for the Daydream controller's touchpad click when used as an emulated Cardboard button.

We indeed rely on long press to open an app menu (there might be other preferable way to do that but at the moment it's the most convenient way to do that for us)

I can easily think of other use case where having start/end support can be important such as object dragging, painting ala tiltbrush, interacting with slider, etc...

Also, probably not the right place to discuss that (or too soon), but it'd be great if the behaviour could be standardize in the webvr spec (unless I miss it).
Especially the fact that events shouldn't be listened on the canvas directly.

+asimjour
We have this same problem generally with out input code, we only send a single tap event on button release, we don't send down and up for the controller.

We should send separate down and up events for both the cardboard trigger and controller.

klausw, what does it mean to be "used as an emulated Cardboard button?"

Regarding standardization, input is an open issue in the WebVR spec [1]. We will likely want to expose common actions (e.g., "primary click") in some consistent way.

[1] https://github.com/w3c/webvr/issues/176

We've gotten rid of the emulated screen touch, but good news is that the new 1-button gamepad controller that replaces it does expose the touch duration. Megan, can you reach out to sketchfab to see if they want to take advantage of this?

bajones: Here's a use case for long-press in the VR Input API.

Removing Blink>WebVR component and assigning to Blink>WebXR