Writing flow: synchronize cross-block selections before events that consume them#80152
Writing flow: synchronize cross-block selections before events that consume them#80152ellatrix wants to merge 1 commit into
Conversation
…onsume them The store receives a cross-block selection from the asynchronous selectionchange event, so a consuming event that arrives first acts on the previous selection: keyboard handling and the clipboard handler read the store's multi-selection at keydown, beforeinput, copy, cut and paste. Process the native selection on capture of those events when it spans blocks; a snapshot of the last processed selection skips the work when the store is already up to date. Selections within one block are synchronized the same way by rich text itself. Also skip dispatching a single-block selection the store already holds: the mouseup after a drag re-processes the selection that the last selectionchange event already dispatched. Co-Authored-By: Claude Fable 5 <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. |
|
Size Change: +284 B (0%) Total Size: 7.71 MB 📦 View Changed
|
|
Flaky tests detected in 8a472d3. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/29218315074
|
1 participant
What?
Update the store with a cross-block selection right before any event that acts on it:
keydown,beforeinput,copy,cutandpaste. The single-block counterpart landed in #80151; this covers selections that span blocks, which the selection observer owns.Why?
The store receives cross-block selections from the asynchronous
selectionchangeevent. When a consuming event arrives first, its handlers act on the previous selection: the clipboard handler copies or replaces the wrong blocks, and typing or pressing Enter over a fresh selection goes through writing flow reading a stale multi-selection.How?
The observer's
selectionchangehandler is also called on capture of the five events when the native selection spans blocks. A snapshot of the last processed selection skips the work when the store is already up to date; without it, re-processing would re-dispatchmultiSelect, which announces the selection to screen readers on every call.Also, the single-block dispatch now skips selections the store already holds: the
mouseupafter a drag re-processed the selection that the lastselectionchangeevent had already dispatched, re-rendering for nothing.Extracted from #79105.
Written with the help of Claude Code.
🤖 Generated with Claude Code