Fix useHomeEnd on tabs in mac testing

[alecgeatches]

What?

Follow-up to #80373 (otherwise independent, but the fixed test is included in this PR to demonstrate the local failure). That PR should get merged first.

While working on that fix, I noticed that the fixed CI test still always failed locally (Mac + Chromium):

$ npm run test:e2e -- test/e2e/specs/editor/blocks/tabs.spec.js --repeat-each=5 -g "adds and activates a new tab"

  # ...
  ✘  1 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (7.0s)
  ✘  2 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (6.2s)
  ✘  3 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (6.2s)
  ✘  4 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (6.2s)
  ✘  5 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (6.1s)

Locally the "End" key press in the test was failing to fire, and a new tab was not being created.

Why?

On trunk, try creating a core/tabs block, entering a tab title mid-line, and hitting the Home or End keys:

home-end-trunk.mov

Above I'm hitting home/end inside of the tab title but nothing happens. In this PR branch, the same test:

home-end-fix.mov

Home and end work properly, and also the test above (which utilizes the End key) passes reliably:

$ npm run test:e2e -- test/e2e/specs/editor/blocks/tabs.spec.js --repeat-each=5 -g "adds and activates a new tab"

> gutenberg@23.6.0-rc.1 test:e2e
> npm exec --workspace @wordpress/e2e-tests-playwright -- wp-scripts test-e2e --config playwright.config.ts test/e2e/specs/editor/blocks/tabs.spec.js --repeat-each=5 -g adds and activates a new tab


Running 5 tests using 1 worker

  ✓  1 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (2.1s)
  ✓  2 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (1.2s)
  ✓  3 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (1.1s)
  ✓  4 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (1.1s)
  ✓  5 [chromium] › specs/editor/blocks/tabs.spec.js:136:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label (1.1s)

  5 passed (9.0s)

How?

macOS maps Home and End to scroll commands, so it never performs caret movement in editable content. Other platforms bind the keys to the proper home and end movements.

#79105 recently added use-home-end.js. When the writing flow wrapper is the contentEditable host (an editableRoot block is selected), no browser performs the "correct" movement for home and end. That's specifically addressed in the editing host case, on the assumption that the browser handles everything else. On macOS the browser doesn't handle home and end in the same way, so any editable that holds focus directly (like tab labels) gets no caret movement at all.

Replace the wrapper-specific guard with a slightly broader editable content check. event.target.isContentEditable is true both for the wrapper when it's the editing host and for a nested editable, and false for inputs, textareas, and other focusables, which keep the browser's default behavior.

Testing Instructions

1. On macOS running on trunk, insert a core/tabs block.
2. Click in the middle of a tab title.
3. Press home/end.
4. See nothing happening.
5. Repeat the same steps in this PR branch (fix/use-home-end-tabs). See the caret move appropriately.

Automated testing

Run the tab test and see it pass locally on macOS:

npm run test:e2e -- test/e2e/specs/editor/blocks/tabs.spec.js --repeat-each=5 -g "adds and activates a new tab"

Use of AI Tools

Claude for the whole process.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Required label: Any label starting with [Type].
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[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: alecgeatches <alecgeatches@git.wordpress.org>
Co-authored-by: ellatrix <ellatrix@git.wordpress.org>
Co-authored-by: noruzzamans <noruzzaman@git.wordpress.org>

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

[alecgeatches]

cc @ellatrix since you worked on #79105 and probably can tell me if this is the right solution. Thanks!

[github-actions]

Size Change: -4 B (0%)

Total Size: 7.73 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-editor/index.min.js	421 kB	-4 B (0%)

_{compressed-size-action}

[ellatrix]

Just to be clear, these tests always failed even before #79105, right? You just want to use the logic added in #79105 for "normal" blocks too? Sounds fine to me.

[noruzzamans]

Thanks @alecgeatches
Tested on macOS and can confirm the issue and the fix.
Steps

1. Inserted a core/tabs block on trunk.
2. Clicked mid-line in a tab title, pressed Home/End.
3. Repeated on the fix/use-home-end-tabs branch.

Observed

• On trunk: Home/End do nothing, caret stays put.
• On the fix branch: caret moves to start/end of the tab label as expected.

Confirms the fix works as intended.

Screen.Recording.2026-07-17.at.8.27.22.AM.mov