-
Notifications
You must be signed in to change notification settings - Fork 1.3k
fix: add isFocusVisible useMenuItem and fix focusRing when typing in Autocomplete SearchField #7625
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
Conversation
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.
Behavior looks good to me.
* for discussion * fix searchfield focus ring appearing on keypress when wrapped in a autocomplete * add test * remove extranous controls
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
} |
Looks like it still comes back? test.focus.ring.movignore the jump after typing "a", that's just storybook shortcuts, not sure why they are happening, but "a" will show and hide the addons panel |
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 might be good to add some chromatic tests for this using the play functions in S2
@yihuiliao good idea, I'll see about doing that as a followup |
Closes
✅ Pull Request Checklist:
📝 Test Instructions:
Ignore the keyboard event leaks causing the storybook controls/bars from appearing/moving. This is known and will be handled when we make collections stop leaking events in general
🧢 Your Project:
RSP