Fix shift+tab behavior to move to toolbar when the preceding block has a form element #51548
Conversation
This file contains 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
…s a form element There was a bug in the tab navigation that allowed tabbing between form elements within a block. Shift + tab in this instance should move to the preceding tabbable element within the current block. However, it wasn't checking if the preceding form element was _within_ the current block, so when at the block boundary, a shift+tab would move to the preceding block's form element rather than the block toolbar. This changes the behavior to constrain the form elements _within the selected block_ and only handle shift+tab or tab if the element being tabbed to is within the current block.
|
Size Change: +4.56 kB (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
scruffian
approved these changes
Jun 16, 2023
There was a problem hiding this comment.
This works as expected and the code looks good to me. One day we might want to make isElementPartOfSelectedBlock a more generic function as part of the block API but for now this looks good. I'll hold off merging to give @alexstine a chance to weigh in too.
alexstine
approved these changes
Jun 16, 2023
There was a problem hiding this comment.
@jeryj To simplify, you may want to have a look at these functions.
https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/utils/dom.js
Other than that, this seems simple enough. Consider adding an E2E test to catch this in the future?
Thanks for the work here.
Thanks for reviewing @scruffian . I only offered because usually contributors get scared of reviewing writing flow PRs. 😆
…mprove performance (#51550)
|
Flaky tests detected in 5aabf43. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5321900631
|
I had planned to add some specific tests around this, but there's an e2e test that does test it as a side effect: 5aabf43#diff-b8ace16c4c4b934a7e25a609558bee7ca033620e880d21baef08d0fa0eb93125R104-R115 Probably better to have something more specific in writing flow though. |
This was referenced Jun 22, 2023
sethrubenstein
pushed a commit
to pewresearch/gutenberg
that referenced
this pull request
Jul 13, 2023
…s a form element (WordPress#51548) There was a bug in the tab navigation that allowed tabbing between form elements within a block. Shift + tab in this instance should move to the preceding tabbable element within the current block. However, it wasn't checking if the preceding form element was _within_ the current block, so when at the block boundary, a shift+tab would move to the preceding block's form element rather than the block toolbar. This changes the behavior to constrain the form elements _within the selected block_ and only handle shift+tab or tab if the element being tabbed to is within the current block. * Combine tests for checking for a navigable toolbar into one test to improve performance (WordPress#51550)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 bug in the tab navigation that allowed tabbing between form elements within a block. Shift + tab in this instance should move to the preceding tabbable element within the current block. However, it wasn't checking if the preceding form element was within the current block, so when at the block boundary, a shift+tab would move to the preceding block's form element rather than the block toolbar.
This changes the behavior to constrain the form elements within the selected block and only handle shift+tab or tab if the element being tabbed to is within the current block.
How?
Check if the element in the natural tab order of
taborshift+tabis going to a tabbable elementTesting Instructions
Testing Instructions for Keyboard
Test blocks with form elements
Test Column/Group Block Tabbing (should be same as on trunk)
Test to preserve behavior from #39085
Screenshots or screencast
Before
Screen.Recording.2023-06-15.at.11.44.43.AM.mov
After
Screen.Recording.2023-06-15.at.11.45.27.AM.mov