Define event order of input sources#629
Conversation
Manishearth
left a comment
There was a problem hiding this comment.
ah, i was wondering how to handle these when thinking in terms of gesture-input like on the Hololens
NellWaliczek
left a comment
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. |
|
Updated to address feedback. Big change is section talking about order of events for non-transient input sources. PTAL! |
NellWaliczek
left a comment
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
recommended primary input
This is a bit confusing? Perhaps say "button"?
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
Fixes #540
Defines the order that events fire in during the handling of transient events.