Skip to content

[menu list] Pressing ArrowUp freezes the page when no item is focusable and focus is on another element in the list #49468

Closed

Description

@Dev-next-gen

Steps to reproduce

Steps:

  1. Render a MenuList where every MenuItem is disabled and another focusable element sits inside the list, for example a search field above a "No results" item:
<MenuList>
  <li>
    <input aria-label="search" />
  </li>
  <MenuItem disabled>No results</MenuItem>
</MenuList>
  1. Click in the input.
  2. Press ArrowUp.

I reproduced it on master with a test in MenuList.test.js (jsdom). The same code ships in @mui/utils 9.5.0 and 10.0.0-alpha.0.

Current behavior

The tab freezes. The test never finishes; I had to kill it after 120 seconds.

MenuList forwards the keydown to useRovingTabIndex. Focus is neither on the container nor on an item, and no item is focusable, so getCurrentActiveItemIndex returns -1. ArrowUp then calls getNextActiveItem(snapshot, -1, 'previous', ...). getNextIndex only treats index 0 as the start of the list for 'previous', so it returns -2, then -3, and so on. The while (nextIndex !== -1) loop never meets -1 or its start index again.

Expected behavior

ArrowUp does nothing (no item can take focus) and the page stays responsive. getNextActiveItem documents -1 as "start before the first item", which getNextIndex already handles for 'next'.

Context

A menu with a search field whose results are all disabled or replaced by a disabled "No results" item.

Your environment

npx @mui/envinfo
Reproduced on mui/material-ui master (e9fabee) with Node 22, vitest + jsdom.
Code path is the same in @mui/utils 9.5.0 (useRovingTabIndex.js, getNextIndex).

Search keywords: menu list arrow up freeze infinite loop disabled useRovingTabIndex

Activity

  1. ZeeshanTamboli commented on Oct 16, 2026

    @ZeeshanTamboli
    Member

    Thanks for the report and the clear analysis. I can confirm it: here's a minimal repro https://stackblitz.com/edit/github-snejgaio.

    Focus the input and press ArrowUp, and the page hangs.

    This is a regression from #47687. v7's DOM-traversal MenuList had a wrappedOnce guard that ended the loop here.

    Side note: a text input inside role="menu" isn't valid ARIA. For search-plus-options UIs, Autocomplete is the recommended component. A keypress still shouldn't freeze the page, so we'll fix it.

  2. added
    scope: menuChanges related to the menu.
    type: regressionA bug, but worse, it used to behave as expected.
    and removed on Oct 16, 2026
  3. github-actions commented on Oct 16, 2026

    @github-actions
    Contributor

    This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
    Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.


    @Dev-next-gen Thanks again for creating this issue! If you have a moment, we would love to hear your thoughts on how we handled it with this short feedback form.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    scope: menuChanges related to the menu.type: regressionA bug, but worse, it used to behave as expected.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions