Remove manual focus tracking for navigation link blocks #72142
Merged
Conversation
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
When we're in the link creation flow, the block currently being created was selected, creating a very unstable state. - If you click off this modal, the link is removed - In the sidebar inspector, the navigation link fields are visible for editing. clicking one of those removes your link, making it impossible to use these visible fields. - If you escape out of the flow, your currently selected block is removed, causing a focus loss. This PR selects the parent navigation block during this unstable link creation phase, so the sidebar shows the parent navigation block state and if you bail on the creation process, it doesn't cause a focus loss. It allows returning focus to the appender by default.
Focus should be going to the appender in most cases. Added checks for this and updated previous tests. Also broke tests into steps.
|
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 If 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. |
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
jeryj
added
[Block] Navigation
|
Size Change: -1.62 kB (-0.08%) Total Size: 1.96 MB
ℹ️ View Unchanged
|
getdave
reviewed
Oct 8, 2025
Contributor
getdave
left a comment
getdave
left a comment
There was a problem hiding this comment.
Took this for a spin. It's a great improvement over trunk!
I found one issue with the Submenu block not getting auto-removed (see screencapture below). This might be considered something to tackle in a followup. If we need to share the "auto removal" behaviour we can put it into shared/ and consume in the Submenu.
Screen.Capture.on.2025-10-08.at.08-57-15.mp4
Contributor
Author
The submenu creation behavior flow you reported is the same as on trunk from what I see, so I think we should address that in a follow-up. |
getdave
approved these changes
Oct 8, 2025
Contributor
getdave
left a comment
getdave
left a comment
There was a problem hiding this comment.
Assuming fixes from previous review get done LGTM.
Could you raise a followup Issue/PR for Submenus? 🙏
|
Flaky tests detected in 8de7385. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18349078501
|
Contributor
Author
|
Contributor
|
Good point. I wonder if people need this flow. It's not a huge deal. I suggest we leave it for now. All good. |
sidharthpandita1
pushed a commit
to sidharthpandita1/gutenberg
that referenced
this pull request
Oct 10, 2025
) When we're in the link creation flow, the block currently being created was selected, creating a very unstable state. - If you click off this modal, the link is removed - In the sidebar inspector, the navigation link fields are visible for editing. clicking one of those removes your link, making it impossible to use these visible fields. - If you escape out of the flow, your currently selected block is removed, causing a focus loss. This commit selects the parent navigation block during this unstable link creation phase, so the sidebar shows the parent navigation block state and if you bail on the creation process, it doesn't cause a focus loss. It allows returning focus to the appender by default.
This was referenced Oct 10, 2025
This was referenced Oct 10, 2025
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.
What?
Fixes and simplifies focus management issues in Navigation Link and Navigation Submenu blocks when closing link popovers. Fixes #68035
Fixes #65962 by moving block selection to the parent block so the sidebar editing isn't available during this step.
Flaky test fixes: Closes #71966, #72064, #72065 and #71108
Why?
After adding a new navigation link and clicking anywhere (inspector, header, etc.), the popover would aggressively steal focus back to the canvas, preventing interaction with other UI elements, instead of letting the click naturally place focus.
How?
Removed the
openedBystate that was tracking which element opened the link popover, as it's no longer needed for focus management since #68060 and #71252 were merged.onClosehandler to:useFocusOutsidevia the popoverAdditional Changes
Test Focus Behavior for New Links
Test Escape Key Behavior for New Links
Test Escape Key Behavior for Existing Links
Test Navigation Submenu Repeat all the above tests with Navigation Submenu blocks to ensure they behave identically.
Before
Screen.Recording.2025-10-03.at.2.13.39.PM.mov
After
Screen.Recording.2025-10-03.at.2.14.08.PM.mov