components/Menu: Restore Modal focus return when menu items close

[ciampo]

What?

Closes #80734.

Restores focus return when a legacy Modal opens from a closing Menu. It also makes the default Modal scroll lock work without WordPress common.css.

The existing hideOnClick behavior is unchanged.

Why?

#77460 made menus unmount immediately to preserve the menu-to-Modal scroll-lock handoff. The focused item now disappeared before Modal captured its focus-return target, so focus returned to the page instead of the root menu button.

How?

When an item is about to close its menu and focus is still inside it, focus moves to the root menu button before Ariakit unmounts the menu. The immediate teardown and Ariakit activation safeguards remain unchanged.

Modal now includes the default body.modal-open { overflow: hidden; } style. Custom bodyOpenClassName values still require their own scroll-lock CSS.

Testing Instructions

1. Open Components / Actions / Menu / With Modal in Storybook with Global CSS: Font only.
2. Open the menu and select Open modal.
3. Confirm that the menu closes and scrolling stays locked.
4. Close the Modal.
5. Confirm that scrolling is restored and focus returns to Open menu.

Testing Instructions for Keyboard

Repeat using Enter to select Open modal.

Screenshots or screencast

Before	After
Kapture.2026-08-04.at.17.41.19.mp4	Kapture.2026-08-04.at.17.47.06.mp4

Use of AI Tools

Codex was used to inspect the regression history and installed source, implement the focused change and tests, and run verification. The resulting diff and test evidence were reviewed locally.

[github-actions]

Size Change: +266 B (0%)

Total Size: 7.65 MB

📦 View Changed

Filename	Size	Change
build/scripts/components/index.min.js	278 kB	+225 B (+0.08%)
build/styles/components/style-rtl.css	18.1 kB	+11 B (+0.06%)
build/styles/components/style-rtl.min.css	15 kB	+10 B (+0.07%)
build/styles/components/style.css	18.1 kB	+10 B (+0.06%)
build/styles/components/style.min.css	15 kB	+10 B (+0.07%)

_{compressed-size-action}

[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: mirka <0mirka00@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: yashjawale <yashjawale@git.wordpress.org>

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

[t-hamano]

I will soon start the release process for 7.1 RC1. Let's consider releasing this PR for RC2 if possible.

[mirka]

I'm doing the test instructions in Storybook, and I noticed that the scroll lock only works when the "WordPress" styles are injected (common.css). It doesn't work with "font only". I think maybe a overflow: hidden is missing on body?

[ciampo]

I'm doing the test instructions in Storybook, and I noticed that the scroll lock only works when the "WordPress" styles are injected (common.css). It doesn't work with "font only". I think maybe a overflow: hidden is missing on body?

I believe that was already the case for Modal prior to this PR, but I agree it makes sense to add overflow: hidden styles to Modal too, which will make it more "standalone"—I went ahead and added them.

I also improved the JSDocs for the bodyOpenClassName prop to make it clear that passing a custom class name there will also require custom handling of the scroll-lock styles (same behavior as currently on trunk, just more explicitly documented).

This PR should hopefully be ready for a final review round.

[mirka]

Also smoke tested in the app 👍

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 13a0338a03ae579ee9298ee99596cb07f789ddee

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.

[t-hamano]

I submitted a PR because the cherry-pick failed. The conflicting part is unrelated to the current logic change, so I intend to merge it after smoke testing if there are no issues. #81446

[github-actions]

There was a conflict while trying to cherry-pick the commit to the wp/7.1 branch. Please resolve the conflict manually and create a PR to the wp/7.1 branch.

PRs to wp/7.1 are similar to PRs to trunk, but you should base your PR on the wp/7.1 branch instead of trunk.

# Checkout the wp/7.1 branch instead of trunk.
git checkout wp/7.1

# Create a new branch for your PR.
git checkout -b my-branch

# Cherry-pick the commit.
git cherry-pick 13a0338a03ae579ee9298ee99596cb07f789ddee

# Check which files have conflicts.
git status

# Resolve the conflict...
# Add the resolved files to the staging area.
git status
git add .
git cherry-pick --continue

# Push the branch to the repository
git push origin my-branch

# Create a PR and set the base to the wp/7.1 branch.
# See https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request.