[react-events] Keyboard support for virtual clicks #16780
Conversation
|
I think this is probably the better place for supporting these kinds of click events, as keyboard interactions also produce "virtual" clicks and you could argue the screen-reader created clicks are also "keyboard" triggered. Since most of the data in the click event is empty (just |
Details of bundled changes.Comparing: 87eaa90...543533b react-events
|
This accounts for all clicks that are natively dispatched following relevant keyboard interactions (e.g., key is "Enter"), as well as programmatic clicks, and screen-reader virtual clicks.
necolas
force-pushed
the
react-events/keyboard-virtual-click
branch
from
9e43f5a
to
543533b
Compare
| nativeEvent.clientX === 0 && | ||
| nativeEvent.clientY === 0 | ||
| ); | ||
| } |
There was a problem hiding this comment.
(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.pointerTypeto 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.
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.
How does (nativeEvent.detail === 0 && !nativeEvent.pointerType) work if that evaluates as true for mouse events as well as virtual clicks?
There was a problem hiding this comment.
(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.
I still don't follow. The click event is of type MouseEvent which has no pointerType property. Are you saying IE11's click event is of type PointerEvent?
There was a problem hiding this comment.
Are you saying IE11's click event is of type PointerEvent?
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.
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.
I'm also curious to hear what you use this check for at Tableau
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.
@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.
This accounts for all clicks that are natively dispatched following relevant
keyboard interactions (e.g., key is "Enter"), as well as programmatic clicks,
and screen-reader virtual clicks.
(Alternative to #16755)