Suggest mode: explain why formatting is refused across a multi-block selection - #81691

What

Fixes finding F-30 from the Suggest mode guided testing pass: https://github.com/adamsilverstein/gutenberg/blob/docs/suggest-mode-testing-2026-08-14/suggest-mode-testing/README.md

Part of the Suggest mode work tracked in #73411. Stacked on suggest/inline-wiring (#80433), same as the rest of this round.

The problem

Flow FS-07 asks for "per-block format suggestions or a clean refusal, never a direct commit" when a selection spans a block boundary. The refusal is clean. With a real two-block keyboard selection in Suggesting mode, Cmd+B leaves both blocks byte-identical - no note, no marker, nothing written.

The trouble is that it is also completely silent. Nothing tells the user a decision was taken. Press bold, get nothing, and the editor reads as broken.

Two corrections to the write-up in the doc, both from measuring rather than assuming:

The refusal is not Suggest mode's doing. With a multi-block selection the writing-flow wrapper becomes the editing host, and useInput calls preventDefault() on its beforeinput - so the browser's native formatBold never reaches the blocks. That guard is core block-editor behavior and it holds in Editing mode too.

And the doc's first proposed remedy, disabling the formatting controls, has nothing to disable. RichTextShortcut and RichTextToolbarButton are both registered from inside a rich text's own format edits, which only render while a single block is selected. With a multi-block selection there is no bold button in the toolbar at all - visible in the before screenshot below, where the toolbar shows only block-level tools. So the remaining option is the doc's second one: say why.

The fix

A small SuggestionMultiBlockFormatNotice component that listens for the inline-format shortcuts while a cross-block selection is live in Suggesting mode, and answers with a snackbar: "Formatting suggestions apply to a selection within a single block."

Details worth calling out:

• It covers the full set of shortcuts @wordpress/format-library registers - bold, italic, underline, link, unlink, strikethrough and code - not just Cmd+B, since all of them go equally quiet.
• The listener attaches only while hasMultiSelection() is true in Suggest mode, so there is no keydown handler on the canvas the rest of the time.
• The event target has to be inside the multi-selection editing host ([data-has-multi-selection="true"], stamped by useWritingFlow). Block selection survives focus moving to the notes sidebar, so hasMultiSelection alone would have fired this notice for a Cmd+B typed into a note reply.
• The notice carries a fixed id, so holding a shortcut down replaces the snackbar rather than stacking a queue of identical ones.
• It is feedback only. The keystroke is not cancelled, so the refusal itself - which is core's, and correct - is untouched.

On the hot files: this touches packages/editor/src/components/provider/index.js and suggestion-mode/index.js, which #81670 and #81674 also edit. The hunks here are two one-line additions in each, in the same import/mount lists, so they should merge cleanly with both.

Remaining gap: this is the "clean refusal" half of FS-07. The other half the flow allows, actually capturing per-block format suggestions across a multi-block selection, is a feature rather than a fix and is not attempted here.

Screenshots

Two paragraphs selected across the block boundary in Suggesting mode, immediately after pressing Cmd+B. Before, only the mode-change snackbar from earlier is on screen and the keystroke leaves no trace at all:

After, the same keystroke explains itself, and still writes nothing:

Testing instructions

1. Enable the Suggestion mode experiment (Gutenberg > Experiments > Suggestion mode).
2. Create a new post with two paragraphs, eg. "First paragraph" and "Second paragraph".
3. Switch to Suggesting from the Options menu in the top bar.
4. Click into the second paragraph, press ArrowUp then Home, then Shift+ArrowDown and Shift+End. Both blocks should now be selected.
5. Press Cmd+B (Ctrl+B on Windows/Linux).
6. Before: nothing happens. No snackbar, no marker, no note, and no bold button in the toolbar to explain itself.
7. After: a snackbar reads "Formatting suggestions apply to a selection within a single block." The blocks are still untouched - check the code editor and confirm there is no wp-suggestion mark and no <strong>.
8. Now select a word inside a single paragraph and press Cmd+B. The format suggestion is captured as before and no snackbar appears.
9. Switch to Editing mode, re-select across the two blocks and press Cmd+B. No snackbar - the notice is Suggest mode only.

Automated coverage

E2E, new file test/e2e/specs/editor/various/suggestion-mode-multi-block-format.spec.js:

• Suggestion mode: formatting across blocks › explains why bold does nothing across a multi-block selection - verified red on the unmodified base branch (element(s) not found waiting for the snackbar), green with the fix. It also asserts the refusal still holds: no mark.wp-suggestion in the canvas, and no wp-suggestion or <strong> in the serialized post.
• Suggestion mode: formatting across blocks › stays silent when the same shortcut lands inside one block - the control. Passes on the base branch and with the fix, so the notice is proven not to fire on the ordinary single-block path. It anchors on the format marker actually being written before asserting the snackbar's absence, so the absence is measured after the flow has had its turn.

Both were run with --repeat-each=5, 10/10 passing.

Unit, new file packages/editor/src/components/suggestion-mode/test/multi-block-format-notice.js - six cases covering the notice firing, repeats replacing rather than stacking, and the four ways it must stay quiet (single-block selection, Editing mode, an event outside the multi-selection host, and a non-format shortcut).

Neighbouring suites: suggestion-mode.spec.js runs 21 passed / 1 failed, the single failure being the known pre-existing "a closed sidebar stays closed when a suggestion is created" (F-17, fixed in #81671, not on this base). Core's multi-block-selection.spec.js runs 123/124 across all three browsers, with one webkit case that passes on re-run.

AI Use

Code and description both written with 🤖 Claude Code. I will review and test.