-
Notifications
You must be signed in to change notification settings - Fork 47.3k
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
[react-events] Keyboard support for virtual clicks #16780
Merged
necolas
merged 1 commit into
facebook:master
from
necolas:react-events/keyboard-virtual-click
Sep 16, 2019
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Not sure what the etiquette on a merged PR is -- please let me know if these comments would be more appropriate in e.g. a new Issue. cc @necolas @trueadm )
I don't believe this works cross-browser.
in IE(11), detail is always
0
, even for mouse-initiated click events. Can check for!nativeEvent.pointerType
to work around this -- all click events in IE11 are PointerEvent, but only real pointer events havepointerType
.in Safari, the screen and client coordinates are present even for a keyboard-initiated click. The client coordinates seem to default to the "center" of the element.
What I've used internally at Tableau for this that works cross-browser is
return (nativeEvent.detail === 0 && !nativeEvent.pointerType);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really awesome feedback. Thank you cc @necolas seems like a valid thing we should be doing too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does
(nativeEvent.detail === 0 && !nativeEvent.pointerType)
work if that evaluates astrue
for mouse events as well as virtual clicks?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(nativeEvent.detail === 0 && !nativeEvent.pointerType)
evaluates to true for "keyboard" clicks, not for mouse events.My investigation showed that
nativeEvent.detail === 0
is sufficient for all evergreen browsers; adding!nativeEvent.pointerEvent
covers the IE11 case. Is that more clear?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't follow. The
click
event is of typeMouseEvent
which has nopointerType
property. Are you saying IE11'sclick
event is of typePointerEvent
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, exactly.
!nativeEvent.pointerType
will be true for all other browsers in all scenarios, and true for IE11 when it's a keyboard-initiated click.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for confirming; we didn't know about that quirk. We'll be sure to incorporate your suggested fix. I like what Safari does here. I'm also curious to hear what you use this check for at Tableau
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#16915
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a long, annoying story -- the short version is there an event normalizer (parallel to React) sitting on top of touch events that interferes with native keyboard click events on button elements. I needed this to differentiate the event sources so it could ignore those from the keyboard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@necolas little bit of unfortunate news -- it appears
detail === 0
also for click events which are dispatched to an<input>
when clicked on a wrapping<label>
, even when clicking with a mouse. Not sure if this is a problem for your purposes, but wanted to give you a heads-up.