-
Notifications
You must be signed in to change notification settings - Fork 32
fix(components): Improve Focus and Blur Experience on Autocomplete v2 #2809
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
Merged
Merged
Changes from all commits
Commits
Show all changes
29 commits
Select commit
Hold shift + click to select a range
1b49367
Don't call onBlur when clicking within the floating menu
jdeichert fbfc8a1
Add test
jdeichert f3e2dea
Merge branch 'master' into JOB-141426/fix-autocomplete-onblur-issue
jdeichert 5cc8061
use approach preventing focus rather than blur
ZakaryH dcfba2f
Revert "use approach preventing focus rather than blur"
ZakaryH c96f3d5
add blur related tests
ZakaryH 8912561
Revert "add blur related tests"
ZakaryH 1c46824
Reapply "use approach preventing focus rather than blur"
ZakaryH 20d4787
fix focus management, fix tests, add new POM method
ZakaryH e3ac533
improve openOnFocus assertions
ZakaryH fee17f3
improve test clarity and quality
ZakaryH 6ec26b6
add coverage for new open/click behavior
ZakaryH a9278ff
colocate ref logic to avoid passing around
ZakaryH ae234a6
reuse existing ref
ZakaryH d0ad2a6
use useClick rather than a separate system to open menu on click
ZakaryH 1b1658d
swap off alerts to a text based 'last action' feedback mechanism to a…
ZakaryH 07f910a
prevent issue with other non interactive elements
ZakaryH 7609a3b
remove redundant focus tracking variable
ZakaryH 2995e7f
remove debouce on clear to improve UX
ZakaryH ee803fd
move flag resetting to improve onFocus behavior too
ZakaryH 33bc739
merge master, resolve conflicts
ZakaryH e37f5b8
add blur and focus logging to example to validate behavior
ZakaryH 7d184b0
add example to illustrate focus behavior
ZakaryH 2ae0880
swap to onPointerDown for better compatibility
ZakaryH 8e3191e
clean up example for typos and usability
ZakaryH d043ec9
remove refs from deps, avoid casting
ZakaryH a776c22
add context to openOnFocus behavior
ZakaryH ddeea9f
unify event prevention, colocate methods in util file
ZakaryH 74dd037
regen props
ZakaryH File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 something I never noticed before.. this makes me think it shouldn't open when clicking it, but it does. The jsdoc comment says
Whether the menu should open when the input gains focus.which also seems to imply that it wouldn't open when clicking on it to focus it.I guess i'm curious in what cases would
openOnFocus=falsebe useful to consumers? Why would they not want the menu to open when focusing via keyboard?Not a blocker of course.
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.
that's fair, it's a little counter intuitive. I added a note in the PR description but that's maybe not the best place since this will likely come up again.
so basically we are saying that a click is very high intent. barring misclicks, you are expressing a desire to use this input. as such, if you click on it and it's closed - we open the menu. it's almost a side effect that clicking causes focus.
pure focus that doesn't come from a click such as tabbing through the form elements is more ambiguous as far as intent. did you want to tab to this Autocomplete and use it, or are you actually trying to get to an element that comes after the Autocomplete in the form.
that's why I'd offer a different behavior at all compared to clicking.
as for a real flow or UX this enables: if you try the web story with the
openOnFocus={false}using the empty actions, then closing the modal you'll notice that we do not open the Autocomplete again when it regains focus from the closed modal. of course it's not the only way to make that happen, but it's definitely one of the simpler ones rather than say moving focus onto the next sibling element rather than the Autocomplete that initiated the Modal open.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.
openOnFocus=trueopenOnFocus=falsethis is all with keyboard interactions. if I clicked then the behavior difference would be limited to only the Autocomplete not re-opening on Modal close/dismiss
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.
Gotcha, that makes sense 👍
I guess my point is that maybe the jsdoc comment could more clearly state what conditions it works under.
Again, not a blocker nor the focus of this PR so I'm not saying we need to update that here.
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 agree with that. I'll see if I can either document it better in the JSDoc, or if not there at least in the component docs.