Fix focus loss from unsync and edit button in navigation link inspector sidebar #72436
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
The unsync and edit button enables the disabled input and removes the button that was focused. This causes a focus loss. I added: - Ref for the input - Ref for knowing if we should focus on next render (we can't focus immediately, as the input is disabled and cannot receive focus) - useEffect to check if we should send focus to the input when hasUrlBinding changes
To avoid potential edge cases, I make shouldFocusURLInputRef ALWAYS get set to false when the useEffect runs. Also, only send focus if hasUrlBinding is false (input enabled)
|
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. |
|
Size Change: +1 B (0%) Total Size: 2.08 MB
ℹ️ View Unchanged
|
jeryj
added
[Focus] Accessibility (a11y)
|
Flaky tests detected in a2cea97. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18596049407
|
scruffian
reviewed
Oct 17, 2025
| const lastURLRef = useRef( url ); | ||
| const dropdownMenuProps = useToolsPanelDropdownMenuProps(); | ||
| const urlInputRef = useRef(); | ||
| const shouldFocusURLInputRef = useRef( false ); |
Contributor
There was a problem hiding this comment.
Is a state more appropriate than a ref here?
Contributor
Author
There was a problem hiding this comment.
I think state would cause an additional render. Also, we don't need this as a state. It's an action we want to perform at a specific time.
If we use state, then it looks like:
- Unlink click -> setShouldFocusInput( true )
useEffect( () => {
if( shouldFocusInput ) {
urlInputRef.current.focus();
setShouldFocusInput( false ); <--- causes this setState to run again with an additional render
}
), [ shouldFocusInput, setShouldFocusInput ] );
I prefer the useEffect that doesn't cause an additional unnecessary rerender
scruffian
reviewed
Oct 17, 2025
Co-authored-by: Ben Dwyer <ben@scruffian.com>
getdave
approved these changes
Oct 20, 2025
Contributor
getdave
left a comment
getdave
left a comment
There was a problem hiding this comment.
This change works as described using a mouse and also using a keyboard.
The focus is correctly applied only when unsyncing entity bound links.
The fix is well scoped and avoids unwanted re-renders.
I appreciate the augmenting of the existing test coverage 👏
Comment on lines
+102
to
+104
| if ( ! hasUrlBinding && shouldFocusURLInputRef.current ) { | ||
| urlInputRef.current?.focus(); | ||
| } |
Contributor
There was a problem hiding this comment.
I think it would be helpful to have a comment here explaining why we need the ! hasUrlBinding.
My understanding is that it's because this logic should only apply when unsyncing an existing binding (effectively when you "unlock" the Link field).
Contributor
Author
There was a problem hiding this comment.
Yeah, it was a defensive coding thing. Not strictly necessary, as it shouldn't happen anyways.
| const { updateBlockAttributes } = useDispatch( blockEditorStore ); | ||
|
|
||
| const editBoundLink = () => { | ||
| const unsyncBoundLink = () => { |
Contributor
There was a problem hiding this comment.
Thanks for renaming this 👍
Comment on lines
+195
to
+197
| // Focus management to send focus to the URL input | ||
| // on next render after disabled state is removed. | ||
| shouldFocusURLInputRef.current = true; |
Contributor
There was a problem hiding this comment.
It's good that we didn't try to abstract this into the unsyncBoundLink. This keeps the fix targetted.
Contributor
Author
There was a problem hiding this comment.
Yup! Wanted to keep things tidy and focused.
ellatrix
added
the
Backport to WP 6.9 Beta/RC
ellatrix
pushed a commit
that referenced
this pull request
Nov 11, 2025
…or sidebar (#72436) Co-authored-by: jeryj <jeryj@git.wordpress.org> Co-authored-by: scruffian <scruffian@git.wordpress.org> Co-authored-by: getdave <get_dave@git.wordpress.org>
Member
|
The bot is failing, I'm not sure why. https://github.com/WordPress/gutenberg/actions/runs/19265984111/job/55081805728
I've manually cherry picked this in a8932f6. |
ellatrix
added
Backported to WP Core
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 a focus loss from the inspector sidebar on navigation links when pressing the unsync and edit button
Why?
The unsync and edit button enables the disabled input and removes the button that was focused. This causes a focus loss. We need to manage focus to meet accessibility standards.
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast