-
Notifications
You must be signed in to change notification settings - Fork 2
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
Fix SelectNext focus inconsistencies when mixing mouse and keyboard interaction #1292
Conversation
@@ -94,6 +94,10 @@ export function useArrowKeyNavigation( | |||
const lastFocusedItem = useRef<HTMLElement | null>(null); | |||
|
|||
useEffect(() => { | |||
if (!containerVisible) { | |||
return () => {}; | |||
} |
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 not strictly related with the other changes on this PR, but I realized we can safely skip any action when containerVisible
is false, making the rest of the logic easier to reason about.
const elements = getNavigableElements(); | ||
const targetIndex = elements.indexOf(event.target as HTMLElement); | ||
if (targetIndex >= 0) { | ||
updateTabIndexes(elements, targetIndex); | ||
updateTabIndexes(elements, targetIndex, autofocus); |
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 what was causing the options to not be set as lastFocusedItem
when being clicked instead of selected with the keyboard.
1468463
to
be01f16
Compare
Codecov Report
@@ Coverage Diff @@
## main #1292 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 62 62
Lines 911 916 +5
Branches 350 351 +1
=========================================
+ Hits 911 916 +5
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
be01f16
to
e4e7fa8
Compare
There's a line not covered, which should be when I'll put this in draft state for now, just in case this ends up having deeper implications. |
80ca5e9
to
c03227d
Compare
Ok, I was missing some |
c03227d
to
9c2adf6
Compare
0e01213
to
1b974d1
Compare
if (e.key === 'Enter') { | ||
selectValue(value); | ||
} | ||
}} |
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 was transparently handled by Buttons
, but needs to be explicitly added for li
s.
1b974d1
to
e8ab7bd
Compare
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.
Just two minor things I spotted with the change to <li>
:
- Space should select the item as well as Enter (I'm not sure if there is a more general way of getting the keys which have activation behavior)
- The cursor should be set to
pointer
Otherwise this looks good to me.
src/components/input/SelectNext.tsx
Outdated
{ 'hover:bg-grey-1': !disabled }, | ||
classes, | ||
)} | ||
onClick={() => selectValue(value)} | ||
onKeyPress={e => { | ||
if (e.key === 'Enter') { |
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.
Also the Space key should select the item.
e8ab7bd
to
98bc0d0
Compare
98bc0d0
to
164a063
Compare
Closes #1285
This PR addresses the two problems left in
SelectNext
, both related with option focusing.:focus-visible
and not:focus
, which prevents the UA from applying the styles. See first example in https://developer.mozilla.org/en-US/docs/Web/CSS/:focus-visible#examplesIn order to fix the first issue, options are no longer
Button
components, but simpleli
where we have to override less styles and we can apply focus rings to:focus
instead of:focus-visible
.This also means the listbox is now a
ul
instead of adiv
.