Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Defining event orders through a "state of the input device" #438

Closed
mustaqahmed opened this issue Mar 15, 2022 · 4 comments
Closed

Defining event orders through a "state of the input device" #438

mustaqahmed opened this issue Mar 15, 2022 · 4 comments
Labels

Comments

@mustaqahmed
Copy link
Member

While working on #437, I realized that a section on "state of the input device" would be useful. I came up with this tentative diagram, wanted to check other people's thoughts.

Here are some benefits I can see:
A. Current spec wording indirectly imply such a state hierarchy, but this is not obvious.
B. The open issues (#285, #357, #400) on event ordering could benefit from this.
C. Device-disconnection vs panning/zooming/DnD lead to two different state of the pointing device. This is not mentioned anywhere. Discussion on hoverable stylus gets confusing without it.
D. We may need to clarify the state distinction in [C] even for #203.
E. The spec is silent that touch-pointers cannot be in "active state" outside "active button state". As a result, pointerout/pointerleave events may appear to mark a transition to inactive state which is clearly wrong.

@flackr
Copy link
Contributor

flackr commented Apr 27, 2022

@mustaqahmed, the pointer captured state in the tentative diagram doesn't agree with my understanding of pointer capture. In particular it suggests that pointer capture is lost before the active button state is lost which means you wouldn't be able to capture up events. I think the capture loss should be deferred until the active state.

@mustaqahmed
Copy link
Member Author

Hmm, fair point about capturing pointerup. Can we perhaps say that in this case the pointerup event forces the implicit release after hit-testing is done so event target is not affected by this state change?

I think logically we cannot be in the captured state without being in the active button state, but the other way around is possible. Current spec wording seems to support this notion by allowing explicit capture only from within the active button state, right? If we don't have this state vs sub-state hierarchy, "active button" vs "captured" would be two partially-overlapped states which IMHO is one source of the complicated event ordering discussions.

@patrickhlauke
Copy link
Member

Discussed in meeting today. Decided to close this issue.

@mustaqahmed
Copy link
Member Author

Closing as discussed today at our PEWG meeting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants