-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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 Select keyboard focus trap #7103
Conversation
a79adcf
to
3013156
Compare
c08096a
to
3503d62
Compare
} else { | ||
triggerRef.current.focus(); | ||
} | ||
}, |
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.
Wonder if the above comment still applies, or whether we could make the input have tabIndex={-1}
now. This is somewhat complicated...
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'll make another branch we can test that on, because, agreed, this is complicated
Closing in favor of #7200 |
Reopening because the other option may break android |
Closing in favor of #7200 |
Closes #7019
Couple assumptions. The only way to focus the hidden select is via keyboard tab/shift+tab. If focus is coming from the document.body (such as if the user clicks near the Select, then hits tab), then focus should just go directly to the Select, not the extra button. We can't tell what the intent was and the behavior of a click followed by tab differs across browsers anyways.
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: