-
Notifications
You must be signed in to change notification settings - Fork 4.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
Set post editor sidebar tabs to manual activation #58041
Conversation
Size Change: +143 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
5c66b31
to
cdb9102
Compare
Flaky tests detected in 2e2b03a. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/7636209195
|
cdb9102
to
2e2b03a
Compare
2e2b03a
to
5dfdeb2
Compare
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.
🚀
packages/edit-post/src/components/sidebar/settings-sidebar/index.js
Outdated
Show resolved
Hide resolved
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. |
1f2c4f8
to
7ae8f38
Compare
This PR should wait for #57696 to be merged ✅
What?
Why?
When #55360 was merged to implement the new
Tabs
component instead of the custom implementation in place previously, the activation method was changed. Previously, thebutton
elements needed to be explicitly activated to select a tab. With that PR the activation became automatic whenever a tab was given focus.In we noticed that automatic activation is more consistent with past behavior when migrating similar settings panels, and this change will bring them all in alignment (see #56959 and #57886)
Regarding tab flow: in the editor sidebars a race condition exists where if no tab is selected, and then the Tab key is used to cycle through all of the existing blocks, the next press of Tab will move focus to the settings sidebar.
When that happens, two events fire independently of each other in this order:
interfaceStore
detects that focus is no longer on a block. The sidebar is automatically switched over the the Post tab.The net result from a user perspective is that pressing Tab that last time focuses one tab wile selecting the other. This feels really confusing, so we're adding a check to prevent that from happening.
How?
selectOnMove
propuseEffect
call that will checks to confirm that the currently selected tab matches the currently focused tab. if not, it updates browser focus so the user experience is Tabing onto the tab that actually gets selected.Testing Instructions