Block Editor: Fix Escape from the block toolbar and stop redundant last focus dispatches

[Mamaduka]

What?

Two related fixes to how the block toolbar returns focus to the canvas, plus e2e coverage for the untested cases.

Why?

lastFocus records the element that the focus left the editor canvas from, so Escape and Shift+Tab can put focus back where the user was. Two problems:

1. Escape has no fallback when nothing has been recorded yet. Insert a block from the global inserter, which leaves focus in the inserter, then press Alt+F10 and Escape. Nothing happens, and there is no way back to the canvas by keyboard. Focus currently selected block when entering canvas #61472 fixed this for the Shift+Tab path but left Escape unguarded.

2. lastFocus was written on every focusout in the canvas, including focus moves between blocks. Nothing reads it reactively, but each dispatch produced a new root state and notified every subscriber of the block editor store, so every useSelect in the editor re-ran.

How?

Escape now falls back to the selected block's element. It is read from the BlockRefs map inside the keydown handler, so the toolbar keeps the non-reactive selection access introduced in #57140, and the lookup works across the iframe boundary. Escape also only prevents default when it has somewhere to move focus to. onFocusOut now records only when focus actually leaves the canvas, as the action's docblock already described.

Testing Instructions

1. Open a new post without clicking into the canvas.
2. Insert a block from the top bar inserter.
3. Press Alt+F10 to reach the block toolbar, then Escape.
4. Focus should move to the inserted block. On trunk, it stays in the toolbar.

Then check the existing behavior still holds. Insert an Image block, press Alt+F10, then Escape. Focus should return to the Upload button rather than the block wrapper. Same via Shift+Tab and Tab.

Use of AI Tools

Assisted by Claude.

[github-actions]

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 props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Size Change: +43 B (0%)

Total Size: 7.82 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	434 kB	+43 B (+0.01%)

_{compressed-size-action}

[github-actions]

Flaky tests detected in 4be0aaf.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/31296733534
📝 Reported tests:

Navigates the items list via UP/DOWN arrow keys in /test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js, passed after 1 failed attempt.

Error: expect(locator).toBeFocused() failed

Locator:  getByLabel('Page Two')
Expected: focused
Received: inactive
Timeout:  5000ms

Call log:
  - Expect "toBeFocused" with timeout 5000ms
  - waiting for getByLabel('Page Two')
    14 × locator resolved to <button type="button" tabindex="-1" aria-pressed="false" id="view-list-0-331-item-wrapper" class="dataviews-view-list__item" aria-labelledby="view-list-0-331-label" aria-describedby="view-list-0-331-description"></button>
       - unexpected value "inactive"

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/site-editor/dataviews-list-layout-keyboard.spec.js:112:49

[Mamaduka]

I plan to merge this. There are no behavior changes; only fixes and PRs improve e2e test coverage.

The Tab order of the block toolbar aligns with visual order test is still a bit flaky, but it's better than on trunk. I plan to debug it further in follow-up.

[jeryj]

Was this an AI overreach on refactoring? I didn't see an explanation for refactoring the e2e tests for scrolling a toolbar. Not opposed but wanting to make sure it was checked and considered.

[Mamaduka]

It was my request for LLM 😅 Saw some opportunity to for refactoring.