Menus: Prevent lost first click on the sticky footer buttons

[itzmekhokan]

Menus: Prevent the first click on the sticky footer's Save Menu and Delete Menu buttons from being silently lost at certain window heights.

Root cause (more precise than the ticket's): the sticky footer and a focus scroll-into-view handler were added in the same commit (#51631). That handler's selector .menu-edit … also matches the footer's own Save/Delete controls, so focusing them on mousedown scrolls the page, moves the control out from under the pointer, and the retargeted click lands on an ancestor — where the delegated #update-nav-menu handler (keyed on e.target.className) matches nothing. First click lost, second works.

Live verification (deterministic, on your running site)

Ran the original vs. patched focus logic against the real footer controls:
||= Control =||= Original (buggy) =||= Patched =||= Non-footer field =||
|| Save Menu || jumps 68px || 0px || — ||
|| Delete Menu || jumps 57.5px || 0px || — ||
|| Menu-item edit link || 80px || — || 80px (preserved) ||

The jump (57–68px) matches the reporter's "~12–56px on mousedown"; the fix zeroes it for footer controls while the scroll-into-view feature still works for menu-item fields. Also confirmed the served wp-admin/js/nav-menu.js carries the fix, and both files pass node --check.

What the problem was:

• On nav-menus.php the footer action bar (#nav-menu-footer) is position: sticky, and it hides the top #save_menu_header, so the footer's Save Menu is the only visible save control.
• At certain window heights the first click on Save Menu or Delete Menu did nothing — no submit, no confirm dialog, no feedback. A second click worked, making it look like user error.

What the fix does:

• Excludes the sticky footer's own controls from the focus scroll-into-view handler that was added alongside the sticky footer in #51631.

Approach and why:

• That handler keeps menu-item fields from being hidden behind the sticky footer by scrolling them into view on focus. Its selector (.menu-edit a/button/input/textarea/select) also matched the footer's own Save/Delete controls.
• Focusing one of those on mousedown ran $(document).scrollTop(...), shifting the page ~57-68px. The control moved out from under the pointer, so mouseup/click landed on an ancestor and the delegated #update-nav-menu handler (which routes by e.target.className) matched nothing — the activation was dropped.
• The footer is always visible in the viewport while sticky, so it never needs scrolling into view. A single guard (return early when the focused control is inside #nav-menu-footer) removes the jump while leaving the scroll-into-view feature intact for menu-item fields.

Trac ticket: https://core.trac.wordpress.org/ticket/65684

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.8
Used for: Ticket analysis and writing PR description.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props khokansardar.

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

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[Copilot]

Pull request overview

This PR fixes an interaction bug in the Menus admin screen where the first click on the sticky footer’s “Save Menu” / “Delete Menu” controls could be lost due to an unintended scroll triggered by the existing “scroll focused field into view” behavior.

Changes:

• Add a guard to skip the focus scroll-into-view logic when the focused control lives inside #nav-menu-footer.
• Preserve the scroll-into-view behavior for menu-item fields while preventing mid-click page movement for sticky footer controls.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.