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]

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: chriszarate <czarate@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

[alecgeatches]

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.

Yes, these failed before. I checked out #79981 (where these tests were added, merged prior to the editableRoot changes) and ran tests:

$ npm run test:e2e -- test/e2e/specs/editor/blocks/tabs.spec.js

  ✘  1 [chromium] › specs/editor/blocks/tabs.spec.js:53:3 › Tabs › Editor functionality › activates the next tab when the caret moves into its label with the right arrow key (6.2s)
  ✘  2 [chromium] › specs/editor/blocks/tabs.spec.js:84:3 › Tabs › Editor functionality › activates the previous tab when the caret moves into its label with the left arrow key (6.2s)
  ✓  3 [chromium] › specs/editor/blocks/tabs.spec.js:115:3 › Tabs › Editor functionality › switches the active tab and selects the tab list when a tab is clicked while a block in another panel is selected (1.1s)
  ✘  4 [chromium] › specs/editor/blocks/tabs.spec.js:146: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:188:3 › Tabs › Editor functionality › removes the tab and activates the previous one when pressing Delete on an empty tab label (1.9s)

  3 failed
    [chromium] › specs/editor/blocks/tabs.spec.js:53:3 › Tabs › Editor functionality › activates the next tab when the caret moves into its label with the right arrow key 
    [chromium] › specs/editor/blocks/tabs.spec.js:84:3 › Tabs › Editor functionality › activates the previous tab when the caret moves into its label with the left arrow key 
    [chromium] › specs/editor/blocks/tabs.spec.js:146:3 › Tabs › Editor functionality › adds and activates a new tab when pressing Enter at the end of a tab label 

The three locally failing tests all use Home or End keys. We just now have a convenient place to fix this issue after your changes. I'd appreciate an approval if you're okay with the new changes!

[t-hamano]

@alexandec @ellatrix, should we backport this PR to 7.1?

[alecgeatches]

@t-hamano I think this should be backported, as running some e2e tests locally doesn't work on a mac without these changes. I don't see any reason to wait either, it seems pretty innocuous. I marked it as backport.

[github-actions]

I just cherry-picked this PR to the wp/7.1 branch to get it included in the next release: 360a6e2

[t-hamano]

I think this should be backported, as running some e2e tests locally doesn't work on a mac without these changes. I don't see any reason to wait either, it seems pretty innocuous. I marked it as backport.

Thank you. Let's also backport this PR to Gutenberg 23.6, which is releasing today. This is to keep WP7.1 and GB23.6 as consistent as possible.

[t-hamano]

I just cherry-picked this PR to the release/23.6 branch to get it included in the next release: 94a9694