Repository navigation
Conversation
|
Size Change: +122 B (0%) Total Size: 7.72 MB 📦 View Changed
|
|
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. |
|
Tested! Confirms the fix works as expected. With a paragraph, spacer, and paragraph, Shift+ArrowDown first selects the paragraph and spacer, a second press selects all three, and Shift+ArrowUp shrinks back to two. One observation: pressing Shift+ArrowUp again from two selected blocks deselects both back to a caret. This wasn't explicitly covered in the testing instructions, so not sure if it's intended, flagging in case it's useful. Screen.Recording.2026-07-25.at.10.43.47.PM.mov |
…hout text Squashed rebase of fix/shift-arrow-skipped-blocks onto current trunk.
fd4f6a4 to
1c78076
Compare
|
Flaky tests detected in 1c78076. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/31655312559 Navigates the items list via UP/DOWN arrow keys in
|
What?
Fixes #53674. Extending a selection with shift+arrow into a block that does not support splitting (a spacer, a separator, a verse) selects that block as a block, instead of overshooting into the block beyond it. The selection grows and shrinks block by block.
Why?
A shift+arrow press moves the native focus to the nearest text position. A spacer has none, so the browser lands in the paragraph beyond it, and the observer faithfully recorded a three-block selection where two were expected. More generally, a partial selection has no value within a block that cannot split or merge: deleting such a selection removes the block whole anyway.
How?
In
use-arrow-nav, at keydown: when the selection focus is at its block's edge in the key's direction and the adjacent block does not support splitting, select up to that block as a block and prevent the browser from acting. The store updates synchronously, so a fast next press cannot race it, and no overshot native selection ever exists. Mid-block presses and adjacent blocks that support splitting are left entirely to the browser, including its column memory. Further presses grow or shrink the block selection one block at a time (#63259 machinery).The trade-off: the keyboard no longer produces a partial text selection ending inside a non-splitting block. Partial selections with a block in between remain possible when the blocks support splitting, and via mouse selection; the copy and cut tests for that case use a paragraph in the middle.
Testing Instructions
Covered by e2e tests asserting each step in all three engines; they fail on trunk.
Use of AI Tools
Written with Claude Code, reviewed and tested by me.