Alt Fix: Prevent focus loss in Firefox when typing in sidebar inputs #72217
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
In Firefox, when typing in a navigation link's canvas label and then switching to the sidebar Text input, focus would jump to the iframe after each keystroke. The issue occurred in to-dom.js when selection.addRange() changed focus from BODY to a contentEditable DIV. The code attempted to restore focus by calling body.focus(), but in Firefox, focusing BODY inside an iframe causes the parent document to focus the iframe element itself. The fix prevents restoring focus to structural elements (BODY, HTML, DIV) and only restores focus to meaningful focusable elements like inputs, textareas, buttons, and contentEditables.
…ret in rich-text selection updates This ensures that the visual caret and selection API are in sync
jeryj
added
[Type] Bug
|
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: 0 B Total Size: 2.03 MB ℹ️ View Unchanged
|
Contributor
|
Do we already have E2E tests for the other scenarios? (Indenting a list and bolding text cursor position)... |
scruffian
approved these changes
Oct 9, 2025
Contributor
scruffian
left a comment
scruffian
left a comment
There was a problem hiding this comment.
This seems like a much simpler fix. Let's hope the tests pass!
|
Flaky tests detected in cc1cc72. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18381650517
|
Contributor
Author
|
Closing in favor of #72221 |
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?
Closes #72168
Alternative to #61374 and #72174
In Firefox, when typing in a navigation link's canvas label and then switching to the sidebar Text input, focus would jump to the iframe after each keystroke.
The issue occurred with
selection.addRange(), as this causes that element to receive focus in Firefox. In Chrome, no focus shift happens.In some instances, we want
selection.addRange()to move focus, such as when restoring focus to the same location when indenting a block item.Why?
We should be able to use the text input in the sidebar to update the label text without focus being stolen.
How?
When focus is outside the canvas iframe (such as editing a sidebar inspector text field), the iframe will say focus is on the body. If focus is on the body, we don't want to steal focus from outside the iframe unless focus outside the iframe is also on its body element. In this instance, the user was likely interacting with the toolbar, and their interaction caused a focus loss, and we'd want to restore focus to the active canvas element. This scenario happens when indenting a list item from the toolbar, for example. The item is indented and focus moves to the list item.
Testing Instructions
IN FIREFOX
Click a navigation link block
In the sidebar, click or Tab to the Text input to update the label
Type in the sidebar input
Focus should remain in the text field and update the on-canvas element
Add a list block with two list items
Indent the second list item from the toolbar
The list item you indented should receive focus
Testing Instructions for Keyboard
Screenshots or screencast