Define event order of input sources by toji · Pull Request #629 · immersive-web/webxr
Fixes #540
Defines the order that events fire in during the handling of transient events.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, i was wondering how to handle these when thinking in terms of gesture-input like on the Hololens
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad we're getting the event ordering nailed down! I'm not 100% clear why this is unique to transient input sources though?
|
|
||
| When a [=transient input source=] for {{XRSession}} |session| begins it's [=primary action=] the UA MUST run the following steps: | ||
|
|
||
| 1. Fire any <code>"pointerdown"</code> events produced by the [=XR input source=]'s action, if necessary. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious about why the first two steps are in this order? I don't think I have strong opinion either way I suppose?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was the order that you had in the explainer. I don't recall us having a conversation about it at any point, but I do recall looking at your PR and wondering if it mattered before deciding that it probably did not and thus wasn't worth discussing.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha, well I don't think I have a strong opinion either?
Regarding why this is for transient sources only: Any of the non-transient input sources I can think of wouldn't be firing interleaved pointer/click events? Also, this is how it was presented in the explainer and the issue in questions (#540) specifically called out that the new explainer text needed to be pulled into the spec.
And yes, that was probably too narrow of a reading of the issue/explainer text on my part. I'll address the feedback soon.
Define the behavior of transient input sources
Define event order of input sources
Updated to address feedback. Big change is section talking about order of events for non-transient input sources. PTAL!
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like the transient section could probably fairly easily be folded into the main event ordering section, but I don't have a strong opinion on this needing to happen.
Thanks for putting this together!
| - An axis | ||
|
|
||
| NOTE: {{XRInputSource}}s with a <code>null</code> {{gamepad}} can still fire {{select}}, {{selectstart}}, and {{selectend}} events to report binary inputs. | ||
| Each [=XR input source=] SHOULD define a <dfn>primary action</dfn>. The [=primary action=] is a platform-specific action that, when engaged, produces {{selectstart}}, {{selectend}}, and {{XRSession/select}} events. Examples of possible [=primary action=]s are pressing a trigger, touchpad, or button, speaking a command, or making a hand gesture. If the platform guidelines define a recommended primary input then it should be used as the [=primary action=], otherwise the user agent is free to select one. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
recommended primary input
This is a bit confusing? Perhaps say "button"?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed that it sounds a bit awkward, but I wanted to be inclusive to inputs such as air taps and voice commands.
|
|
||
| </div> | ||
|
|
||
| Sometimes platform-specific behavior can result in a [=primary action=] being interrupted or cancelled. For example, a [=/XR input source=] may be removed from the [=/XR device=] after the [=primary action=] is started but before it ends. |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there other reasons for this to occur? If not, perhaps it would make the spec text clearer if we landed a fix for the issue described in this comment #628 (comment) first?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are other reasons, I'm just not sure how many we really want to get into in the spec text? For example: If you started a mouse click on an inline canvas and then moved the cursor off before releasing?