Define event order of input sources #629
Conversation
index.bs
Outdated
|
|
||
| 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. |
toji
changed the title
|
Updated to address feedback. Big change is section talking about order of events for non-transient input sources. PTAL! |
index.bs
Outdated
| @@ -1206,16 +1200,46 @@ The <dfn attribute for="XRInputSource">gamepad</dfn> attribute is a {{Gamepad}} | |||
| - A button which reports analog values | |||
| - 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.