DOM: Fix collapsed range boundary at line wraps Firefox bug#76954
Open
DOM: Fix collapsed range boundary at line wraps Firefox bug#76954
Conversation
This was referenced Apr 1, 2026
bd27979 to
3d37f24
Compare
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @nyanpasu64. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. 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: +82 B (0%) Total Size: 7.73 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 3d37f24. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23840582730
|
t-hamano
reviewed
Apr 1, 2026
Contributor
t-hamano
left a comment
There was a problem hiding this comment.
Thanks for the PR!
This PR works correctly for the up arrow case, but it seems to change the behavior for the down arrow.
- Move the cursor to the beginning of the last line of the paragraph
- Press the down arrow key.
✅ trunk: The cursor moves to the end of the last line.
before.mp4
🤔 This PR: The cursor moves to the next paragraph.
after.mp4
Should this fix be applied only to upward movements?
diff --git a/packages/dom/src/dom/is-edge.js b/packages/dom/src/dom/is-edge.js
index 322fda9bc39..6347bb63d0d 100644
--- a/packages/dom/src/dom/is-edge.js
+++ b/packages/dom/src/dom/is-edge.js
@@ -120,7 +120,7 @@ export default function isEdge( container, isReverse, onlyVertical = false ) {
// Firefox bug where collapsed ranges at line-wrap boundaries report the
// previous line's position.
const verticalRangeRect =
- onlyVertical && isCollapsed
+ onlyVertical && isCollapsed && isReverse
? getAdjacentCharRect( collapsedRange ) ?? rangeRect
: rangeRect;
Member
Author
While the issue only reports a problem with
It looks like I missed that. Will try to fix it. |
Is that not the correct behavior? It matches the arrow key movement behavior of Notepad, browser text fields, rich text word processors, and complex code IDEs. |
Contributor
I don't think so. This is because differences in behavior occur between Chrome and Firefox. We cannot allow special behavior only in Firefox. If this behavior is indeed the correct one, we need to discuss it in a separate issue and change the behavior across all browsers. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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 #34215.
Alternative to #71205. Doesn't use browser check, which is usually a fragile fix.
Fixes a Firefox bug where arrow key navigation (both up and down) incorrectly jumps to the wrong block at line-wrap boundaries.
Why?
Firefox reports the previous line's position for collapsed ranges at line wrap boundaries. This caused
isVerticalEdgeandcomputeCaretRectto misjudge which line the caret is on, leading to incorrect navigation.This report is the closest I could find to the issue - https://bugzilla.mozilla.org/show_bug.cgi?id=1014738.
How?
When the selection is collapsed inside a text node, we get the rect of the next character (offset to offset+1) instead of the collapsed range rect. This gives the correct visual line position. The logic is extracted into the
getAdjacentCharRectmethod, reused bycomputeCaretRectandisEdge.Testing Instructions
Testing Instructions for Keyboard
Same.
Screenshots or screencast
Before
CleanShot.2026-04-01.at.12.39.24.mp4
After
CleanShot.2026-04-01.at.12.38.58.mp4
Use of AI Tools
Used Claude to validate possible solution (browser check, increased tolerance, etc). The solution is tested and reviewed by me.