Update @ariakit/react to 0.4.29

[ciampo]

What?

Closes #79051

Bumps @ariakit/react from ^0.4.21 to ^0.4.29 in @wordpress/components and @wordpress/dataviews (keeping the ranges aligned, as in #77954), and adopts the upstream Tabs focus fix that this range ships — removing the now-unnecessary Gutenberg workarounds.

Why?

#77954 parked the upgrade at ^0.4.21 because a patch in this range changed how controlled Tabs handle focus, breaking 4 unit tests.

That change is intentional: it's the canonical fix for ariakit/ariakit#4213 (which I originally reported). Upstream now moves focus to the newly selected tab on a controlled selectedId change, instead of preventing activeId from updating. So the chain of Gutenberg workarounds that kept focus and activeId in sync is no longer needed.

More detail

The fix shipped in ariakit/ariakit#6068, documented in the 0.4.29 changelog:

Fixed Tab to move focus to the selected tab after a controlled selectedId update while a tab has DOM focus.

The removed workarounds (#56658 → #57696 → #58625) existed to fix the exact desync that #4213 now addresses upstream.

How?

• Bumped @ariakit/react to ^0.4.29 and updated the lockfile.
• Removed the controlled-mode focus workarounds (the requestAnimationFrame re-sync in Tabs and the onBlur re-sync in Tabs.TabList).
• Updated the 4 controlled-selection unit tests to expect focus to follow the selection.
• Refreshed 4 ToggleGroupControl snapshots for an auto-generated name attribute on Radio (see changelog review).

Changelog review (0.4.22 → 0.4.29)

I reviewed every CHANGELOG entry in the range against our actual usage. Only two changes produce observable output, both handled here:

• 0.4.29 — Tab focus follows controlled selection.
• 0.4.26 — Radio auto-generates a name from the RadioGroup id, adding a name attribute to ToggleGroupControl radios (snapshot-only).

Everything else is either a bug fix that improves a primitive we use or doesn't touch one. CI backs this up: the full unit + e2e suites pass with only the two changes above.

Full per-release breakdown and impact on our usage

Ariakit is used only in @wordpress/components (Tabs, Menu, CustomSelectControl v2, Composite, Toolbar, Tooltip, RadioGroup/ToggleGroupControl, Disclosure) and @wordpress/dataviews (one Combobox with autoSelect="always"). We don't use Dialog, Popover, Portal, Focusable, Button, Form/FormRadio, Checkbox, or ComboboxDisclosure directly, though Menu/Select/Tooltip extend Dialog/Popover/Portal internally.

Version	Change	Impact
0.4.29	Tab moves focus to the selected tab after a controlled selectedId update	✅ Adopted here; replaces our workarounds.
0.4.29	Menu crash fix; MenuItem registers only while visible	Positive; our menu tests query items only while open.
0.4.29	Combobox no longer drops characters on resize (autoSelect)	Positive; relevant to the dataviews search widget.
0.4.29	CompositeItem keeps its enclosing store; non-element event targets no longer throw; TooltipProvider loop fix; perf + process.env.NODE_ENV fixes	Positive/defensive.
0.4.29	Button/Dialog/Form fixes	Not used directly — no impact.
0.4.28	npm provenance	No impact.
0.4.27	Menu respects autoFocusOnShow={ false }	Positive; we don't rely on it, so no change.
0.4.26	Auto-generated name on Radio	✅ Snapshots refreshed here.
0.4.26	Popup-window events; Portal in fullscreen; render prop merging with falsy values; Combobox Enter/MenuButton a11y fixes	Positive; no regression surfaced.
0.4.26	Math.random() skipped with explicit id (Next.js)	No impact.
0.4.25	Clicking outside no longer restores focus to the disclosure (Dialog/Menu/Popover)	Behavior change to note; matches native <dialog>. Our outside-click test only asserts closing, so it passes.
0.4.25	TabPanel re-evaluates tabbable children when visible; drops aria-labelledby when aria-label set; Safari focus + typeahead fixes	Positive; no observable diff in our coverage.
0.4.24	Combobox/SelectItem scroll & focus fixes (autoSelect, iOS Safari); crash on id={ undefined }	Positive; relevant to the dataviews combobox.
0.4.24	FormRadio/CheckboxProvider fixes	Not used — no impact.
0.4.23	ComboboxDisclosure Escape fix	Not used — no impact.
0.4.22	MenuItemRadio controlled reset states	Positive; used by our radio menu items.

Testing Instructions

1. npm run test:unit -- packages/components/src/tabs — all Tabs tests pass.
2. npm run test:unit -- packages/dataviews — all tests pass.

Manual keyboard check (Site Editor)

Verify the previously-fixed real-browser scenario still behaves correctly:

1. Open a template in the Site Editor.
2. Move keyboard focus into the editor settings sidebar tabs.
3. Trigger a state change that updates the selected tab while a tab is focused (e.g. select/deselect a block so the sidebar switches between Block and the other tabs).
4. Confirm focus follows the newly selected tab and arrow-key navigation still works.

Use of AI Tools

This PR was authored with the assistance of an AI coding agent (changelog investigation, the bump, removal of the workarounds, and test updates). All changes were reviewed by me.

[github-actions]

Size Change: +2.83 kB (+0.03%)

Total Size: 8.44 MB

📦 View Changed

Filename	Size	Change
build/modules/content-types/index.min.js	159 kB	+627 B (+0.4%)
build/scripts/components/index.min.js	264 kB	+624 B (+0.24%)
build/scripts/edit-site/index.min.js	297 kB	+581 B (+0.2%)
build/scripts/editor/index.min.js	466 kB	+385 B (+0.08%)
build/scripts/media-utils/index.min.js	114 kB	+609 B (+0.54%)

_{compressed-size-action}

[ciampo]

Switched from Ariakit.useStoreState to useStoreState to prevent an eslint error complaining about selectOnMove being used only after the early if ( ! store ) { check. The alternative was to keep the old syntax and add a eslint disable comment

[ciampo]

The tweaks in unit tests describe the behaviour change. The upstream ariakit changes fix the same "out of sync" bug between focused element and activeId that the custom workaround (removed in this PR) also fixed, but with an opposite approach:

• the custom workaround (that is being removed in this PR) fixed the desync by pinning activeId back to the focused tab. In other words, focus stays on beta, selection moves to gamma. Focus and selection are decoupled.
• the upstream fix (which is being adopted in this PR) moves the DOM focus to the selected tab. In other words, focus moves to Gamma, matching selection. Focus and selection are coupled

Our previous approach respected user focus (in exchange for focus and selection going out of sync), while ariakit prioritizes matching focus with selection.

I don't think one approach is clearly better than another, they are just different compromises. With the new approach, the only "awkward" scenario is when selectOnMove: false: I believe the APG suggests keeping focus decoupled from selection, but in practice the change is small: focus is moved only when a tab already has dom focus and the value changes programmatically.

[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: ciampo <mciampini@git.wordpress.org>
Co-authored-by: manzoorwanijk <manzoorwanijk@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

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

[manzoorwanijk]

This looks good from the upgrade perspective.

[ciampo]

Thank you!

I'll also wait for @WordPress/gutenberg-components to take a look

[aduth]

LGTM 👍

I had some trouble trying to follow the manual testing instructions, as I was hoping to validate the regression with the old version installed + code removal and then after. But trying to emulate a state change like selecting a block causes the block itself to receive focus. Tabbing back to the tabs retained focus and allowed switching as I'd expect, both on 0.4.21 and 0.4.29 after these code changes 🤷

Aside from that, the code changes look like an effective revert of the workarounds, and I agree with the assessments on the test behavior changes and other changelog notes.

Happy to collaborate on this tomorrow if you want to dig into validating the specific regression fix.

[ciampo]

Given that the edge case where the behaviour is changes is rare and hard to reproduce, and that the alternative provided from ariakit still feels reasonable, I think we should merge this PR and watch out for any incoming feedback in the upcoming weeks leading to 7.1.