Tabs: Remove editor-only block context

[t-hamano]

What?

Removes editor-only block context from the Tabs block family and derives the same values ad-hoc inside the consuming blocks instead.

Why?

Block context should be reserved for data that genuinely needs to cross block boundaries.

How?

• core/tabs-activeTabIndex, core/tabs-editorActiveTabIndex: These merely expose the attributes of the core/tabs block as context. They can be derived directly via the store on the consumer side. These are not used at all on the server side.
• core/tabs-list: This contains information related to core/tab-panel, which is necessary for the core/tab-list block. However, this information can be derived from the block itself. Since it is used on the server-side, we will keep it as usesContext.
• core/tabs-id: It was not used on the editor side in the first place. However, since it is used on the server side, we will leave it as useContext.
• Change the arguments of the useTabListItemsSync hook to only the clientId of the core/tabs block. The core/tab-list and core/tab-panels blocks, which are necessary for synchronization, can be derived directly within the hook.

Testing Instructions

Smoke test this block in the editor. No errors should occur, and it should function as before.

Use of AI Tools

This PR was authored with the assistance of Claude Code (Anthropic). All changes were reviewed by the author.

[github-actions]

Size Change: -139 B (0%)

Total Size: 7.67 MB

📦 View Changed

Filename	Size	Change
build/scripts/block-library/index.min.js	331 kB	-139 B (-0.04%)

_{compressed-size-action}

[t-hamano]

Small cleanup: isSelectedTab is now a plain derived boolean instead of a useMemo, which was memoizing a zero-cost expression.

[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: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: mcsf <mcsf@git.wordpress.org>
Co-authored-by: jeryj <jeryj@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]

Flaky tests detected in ec6fe8f.
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/28658497189
📝 Reported issues:

• [Flaky Test] activate block theme when live previewing in edit mode #77712 in /test/e2e/specs/site-editor/activate-theme.spec.js

[Mamaduka]

Not a requirement for this PR, but it would be nice to add some basic e2e tests for this block.

[Mamaduka]

Deriving this value within useSelect produced a warning. Fixed via 0c72520.

Screenshot

[Mamaduka]

A nice cleanup, @t-hamano! The changes look good to me, and I couldn't post any regressions.

@mcsf, @jeryj, would appriciate a second set of eyes on this.

[mcsf]

Hey, friends. Is the goal to eradicate editorActiveTabIndex in a subsequent PR? Otherwise I think we're missing the most important issue in this PR, unfortunately. To quote my comment:

Do we need to model in-editor interactivity state as attributes (editorActiveTabIndex)? This looks very much like what I saw in the Playlist block.).

Unless there's an unavoidable problem that I'm missing, we should absolutely not have that kind of state encoded as a block attribute. Then, before stabilising the block, I'd love to rename activeTabIndex to something like defaultTabIndex or initialTabIndex, because that attribute should be a seed for the Interactivity API.

[mcsf]

Before I file an issue, could I get confirmation that the Tabs block family is broken in trunk on Safari (v26.5, macOS 15.7)? 🙏

In editor (no issues)	Front end (no interactivity)
	tabs-safari-frontend.mov

[Mamaduka]

@mcsf, it's working for me locally, tested on the latest trunk and on this branch. Same results in Chrome and Safari (Version 26.5 (21624.2.5.11.4))

[t-hamano]

Is the goal to eradicate editorActiveTabIndex in a subsequent PR?

I considered this as well, but decided not to address it in this PR because it seems difficult to derive equivalent information without context. However, this attribute is a local role and will not be serialized into the saved content.

[t-hamano]

Before I file an issue, could I get confirmation that the Tabs block family is broken in trunk on Safari (v26.5, macOS 15.7)? 🙏

@mcsf, I would be happy to investigate if you could report the problem in #73230 or a new issue.

[jeryj]

Is the goal to eradicate editorActiveTabIndex in a subsequent PR?

I'm testing on trunk and it doesn't look like this current active index is working well to communicate state to the tab content area. When clicking from the content area to a tab, it doesn't select the tab or update the content area to match.

Screen.Recording.2026-07-07.at.10.19.50.AM.mov

[t-hamano]

I'm testing on trunk and it doesn't look like this current active index is working well to communicate state to the tab content area. When clicking from the content area to a tab, it doesn't select the tab or update the content area to match.

I was able to reproduce the issue as well. It's likely caused by conflicting effects updating editorActiveTabIndex. I have a hunch about the cause.

In any case, there should be no regressions caused by this PR, so let's merge it and address any newly discovered issues in a follow-up.

[mcsf]

Before I file an issue, could I get confirmation that the Tabs block family is broken in trunk on Safari (v26.5, macOS 15.7)? 🙏

@mcsf, I would be happy to investigate if you could report the problem in #73230 or a new issue.

I can no longer repro ¯\_(ツ)_/¯