Don't move focus within the toolbar if it is already focused #58570
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
If the toolbar has focus already, we don't want to run a requestanimationFrame to then move focus to the previously unmounted index. Adding a check to see if focus is within the toolbar already, then not running the RAF fixes an issue where moving the block via the mover arrows would steal focus to the index before mount. Also added a fix for getAllFocusableToolbarItemsIn to not exclude aria-disabled buttons, as those can still receive focus.
|
Size Change: -832 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
jeryj
added
[Type] Bug
|
Flaky tests detected in dcd182b. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7758939262
|
Mamaduka
reviewed
Feb 2, 2024
Comment on lines
+276
to
+279
| await expect( blockToolbarMoveUpButton ).not.toHaveAttribute( | ||
| 'aria-disabled', | ||
| 'true' | ||
| ); |
There was a problem hiding this comment.
Suggested change
| await expect( blockToolbarMoveUpButton ).not.toHaveAttribute( | |
| 'aria-disabled', | |
| 'true' | |
| ); | |
| await expect( blockToolbarMoveUpButton )toBeEnabled(); |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core SVNIf you're a Core Committer, use this list when committing to GitHub Merge commitsIf you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Mamaduka
reviewed
Feb 2, 2024
Comment on lines
+286
to
+289
| await expect( blockToolbarMoveUpButton ).toHaveAttribute( | ||
| 'aria-disabled', | ||
| 'true' | ||
| ); |
There was a problem hiding this comment.
Suggested change
| await expect( blockToolbarMoveUpButton ).toHaveAttribute( | |
| 'aria-disabled', | |
| 'true' | |
| ); | |
| await expect( blockToolbarMoveUpButton ).toBeDisabled(); |
There was a problem hiding this comment.
In this case, it has aria-disabled, but not disabled, so it can still be focusable. It looks like toBeDisabled only checks for disabled property:
This custom matcher does not take into account the presence or absence of the aria-disabled attribute. For more on why this is the case, check testing-library/jest-dom#144.
There was a problem hiding this comment.
This is the Playwright assertion, which checks both - https://playwright.dev/docs/api/class-locatorassertions#locator-assertions-to-be-disabled.
Element is disabled if it has "disabled" attribute or is disabled via 'aria-disabled'.
There was a problem hiding this comment.
Ugh. Can't believe I missed that. Sorry! I'll add another little PR. Thanks for correcting me!
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.
Fixes #58511
What?
If the toolbar has focus already, we don't want to run a requestanimationFrame to then move focus to the previously unmounted index.
How?
Adding a check to see if focus is within the toolbar already, then not running the RAF fixes an issue where moving the block via the mover arrows would steal focus to the index before mount.
Also added a fix for getAllFocusableToolbarItemsIn to not exclude aria-disabled buttons, as those can still receive focus.
Testing Instructions