WRR-11058: Update editable scroller focus behavior to match the latest UX #1787
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.
Checklist
Issue Resolved / Feature Added
Focus behavior of the editable scroller is updated
(1) After moving focus to the top button(item is not selected), focus will be moved by pressing the ← or → keys
(2) After entering the item edit mode, item can be moved by pressing the ← or → keys while focusing on the top button
Resolution
Fix
handleKeyDownCapture
to move focus according to updated UX guideAdditional Considerations
(1) To fix the issue as the gif below, I added 6084876 commit.
The issue occurs when focus moves to the
hide
button, scroll event occurred and thenhandleMoveItemsByScroll
executed.I added to set
lastInputType
tokey
to preventhandleMoveItemsByScroll
from being executed.(2) Since there is no guide for these cases, I implemented it as follows.
(3) I added 92fd7fc commit to fix the a11y issue which caused by the logic which manually focus the item.
Links
WRR-11058
Comments