fix: add isFocusVisible useMenuItem and fix focusRing when typing in Autocomplete SearchField #7625
Conversation
| @@ -343,7 +343,6 @@ export const MenuItem = /*#__PURE__*/ createLeafComponent('item', function MenuI | |||
| selectionManager | |||
| }, state, ref); | |||
|
|
|||
| let {isFocusVisible, focusProps} = useFocusRing(); | |||
There was a problem hiding this comment.
removing this means we won't respond to the isFocusVisible state change anymore, it'll be only driven by and checked during renders, so we may miss an interaction mode change right?
There was a problem hiding this comment.
yeah, I suppose so but useFocusRing only updated on focus changes anyways, which meant that the focus ring would remain when you hovered the currently focused item despite the modality being pointer at that point. Now the focus ring will disappear when hovering a previously keyboard focused item. Open to discussion as to whether or not we consider that a bug fix or a unintended change in functionality. One thing to note is that Listbox behaves the same way
There was a problem hiding this comment.
Listbox behaves as Menu does in this PR you mean?
There was a problem hiding this comment.
yep, thats correct. The change here brings Menu in line with Listbox behavior
* for discussion * fix searchfield focus ring appearing on keypress when wrapped in a autocomplete * add test * remove extranous controls
LFDanLu
changed the title
| // For keyboard events that occur on a non-input element that will move focus into input element (aka ArrowLeft going from Datepicker button to the main input group) | ||
| // we need to rely on the user passing isTextInput into here. This way we can skip toggling focus visiblity for said input element | ||
| isTextInput = isTextInput || |
There was a problem hiding this comment.
So it turns out that we still need isTextInput since it allows elements to NOT get focusVisible styles when focus moves from a non-input element via some other method than Tab. This happens for Datepicker on main via the following steps:
- click into the datepicker date input
- using ArrowRight, move focus on to the Datepicker button. Note the focus ring appears for the button
- using ArrowLeft, move focus on to the Datepicker input again. Note the focus ring doesn't appear on the Datepicker group
A bit debatable if this is desired behavior perhaps, I would've liked to simply deprecate isTextInput but the removal of this behavior would be a breaking change for anyone who was relying on it previously
## API Changes
@react-aria/focus/@react-aria/focus:isFocusable isFocusable {
- element: Element
+ element: HTMLElement
returnVal: undefined
}@react-aria/menu/@react-aria/menu:MenuItemAria MenuItemAria {
descriptionProps: DOMAttributes
isDisabled: boolean
+ isFocusVisible: boolean
isFocused: boolean
isPressed: boolean
isSelected: boolean
keyboardShortcutProps: DOMAttributes
menuItemProps: DOMAttributes
}@react-aria/test-utils/@react-aria/test-utils:triggerLongPress triggerLongPress {
opts: {
element: HTMLElement
advanceTimer: (number) => void | Promise<unknown>
- pointerOpts?: Record<string, any>
+ pointerOpts?: {
+
}
+}
returnVal: undefined
}@react-aria/utils/@react-aria/utils:isFocusable-isFocusable {
- element: Element
- returnVal: undefined
-}/@react-aria/utils:isTabbable-isTabbable {
- element: Element
- returnVal: undefined
-}@react-spectrum/test-utils/@react-spectrum/test-utils:triggerLongPress triggerLongPress {
opts: {
element: HTMLElement
advanceTimer: (number) => void | Promise<unknown>
- pointerOpts?: Record<string, any>
+ pointerOpts?: {
+
}
+}
returnVal: undefined
} |
Closes
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: