List View: Place caret at end of block when selecting#76797
List View: Place caret at end of block when selecting#76797
Conversation
When selecting a block from the List View, the caret is now placed at the end of the block instead of the start. This ensures that pressing Enter after selecting a block creates a new block after the selected block, matching user expectations. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove unused `page` and `pageUtils` destructured params and fix prettier formatting in toMatchObject assertions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
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. |
talldan
left a comment
There was a problem hiding this comment.
This change makes sense to me.
Caveat that i haven't been able to manually test it due to env issues.
|
Size Change: +28 B (0%) Total Size: 7.73 MB
ℹ️ View Unchanged
|
getdave
left a comment
There was a problem hiding this comment.
Tested and works as described.
I'm assuming that if the focus position was important (i.e. it needed to be at the beginning of the block for any reason) it would be covered by tests.
🚢
Co-authored-by: Dave Smith <getdavemail@gmail.com>
Mayank-Tripathi32
left a comment
There was a problem hiding this comment.
Works as expected.
Test.Carets.2.mov
After the focusPosition: -1 change, clicking a block in the List View transfers focus to the canvas. The copy and cut tests relied on focus staying in the list view for keyboard operations. Fix by refocusing the list view link after the click. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The focusPosition: -1 change transfers focus to the canvas when clicking a block in the List View. Tests that click a list-view link then use keyboard operations (ArrowRight to expand, Backspace to delete, Shift+Arrow to multi-select) need to refocus the list view after clicking. Fixes: - block-removal.spec.js: ArrowRight expansions and Backspace deletion - multi-block-selection.spec.js: ArrowUp/Down keyboard navigation Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Instead of always passing focusPosition: -1 when clicking a block in the List View, differentiate between mouse clicks and keyboard activation (Enter/Space). Mouse clicks keep focus in the list view for keyboard operations (arrow navigation, copy/paste, multi-select). Keyboard activation transfers focus to the canvas with the caret at the end of the block. This fixes the original issue (pressing Enter after selecting from List View creates a block after, not before) while preserving list view keyboard interactions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…r change Mouse clicks in list view now keep focus in the list view (passing null as focusPosition). The test needs to explicitly press Enter after clicking a column to keyboard-activate it and transfer focus to the canvas before navigating with ArrowDown to open the block inserter. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
What?
Closes #76774
Places the caret at the end of a block (instead of the start) when selecting a block from the List View panel via keyboard activation (Enter/Space).
Why?
When selecting a block via List View, the caret was placed at the start of the block. This meant pressing Enter would create a new block before the selected block, which is unexpected. Users expect a new block to be created after the selected block.
How?
Uses
event.detailto distinguish between mouse clicks and keyboard activation (Enter/Space) in the List View'sselectEditorBlockhandler (block.js):event.detail === 0): Passes-1as thefocusPosition, which tellsuseFocusFirstElementto place the caret at the end of the block and transfer focus to the canvas. This matches standard tree grid semantics — pressing Enter on a list item activates it, moving focus into the canvas for editing.event.detail >= 1): Passesnullas thefocusPosition, which preventsuseFocusFirstElementfrom transferring focus to the canvas. This keeps focus in the List View so that subsequent keyboard operations (arrow navigation, copy/paste) continue to work as expected.Why the distinction is necessary
The
useFocusFirstElementhook has[initialPosition, clientId]as its effect dependencies. Previously,selectBlockwas called with the defaultinitialPositionof0(caret at start). When clicking the same block again, the value stayed0 → 0— no dependency change, so the effect didn't re-run, and focus stayed in the List View. This was coincidental but correct behavior.Simply changing to
-1(caret at end) would cause0 → -1— a dependency change — which would make the effect re-run and steal focus from the List View on every mouse click. By passingnullfor mouse clicks, we explicitly opt out of the focus transfer (sinceuseFocusFirstElementreturns early fornull/undefined), while still getting the desired "focus canvas at end of block" behavior for keyboard activation.Testing Instructions
Mouse click (focus stays in List View)
Keyboard activation (focus moves to canvas)
Use of AI Tools
This PR was authored with the assistance of Claude Code (Claude Opus 4.6).