[material-ui][Chip] Focus issue with Modal/Drawer/Menu

[statecs]

Steps to reproduce

Link to live example: https://codesandbox.io/p/sandbox/mui-chip-focus-bug-c9tlpv

Steps:

1. Use TAB key to focus on a Chip component.
2. Press Space to activate the Chip and open the Menu or Drawer component.
3. Press ESC to close the Menu or Drawer.
4. Observe that the Chip is not refocused.

Current behavior

After closing the Menu or Drawer, the Chip component loses focus. It briefly shows focus-visible styling, which then disappears. This prevents reactivation of the Chip through the Space key, as it's no longer focused.

Expected behavior

The Chip should regain focus with visible focus highlighting after the Menu or Drawer is closed, allowing users to reopen the Menu/Drawer with the Space key.

Context

This issue is causing unpredictable keyboard behavior in applications that use the Chip component to trigger modals and menus.

Additional Information:
Discussion has been made regarding the implementation of Chip for toggling menus and modals, with comparisons to Google Flights filters and Material Design specifications. The behavior of Chip and Button components in this context is a subject of debate. A workaround has been proposed but leads to a focus trap issue.

Request:
Further investigation and potential implementation of a solution to ensure consistent and accessible behavior of the Chip component when used with Modal, Drawer, or Menu components.

Your environment

npx @mui/envinfo

CodeSandbox based on Basic Menu example in MUI 5.15.3
Chrome version 120.0.6099.199 (Official Build) (arm64) on MacOS

Search keywords: chip

[ZeeshanTamboli]

Discussion has been made regarding the implementation of Chip for toggling menus and modals, with comparisons to Google Flights filters and Material Design specifications. The behavior of Chip and Button components in this context is a subject of debate. A workaround has been proposed but leads to a focus trap issue.

I assume you're referring to issue #35149. I'll let @siriwatknp decide.

[DiegoAndai]

Thanks for the report and the well-explained repro, @statecs!

I think this is a bug, aside from the discussion you mentioned. We currently support this use case, so keyboard navigation should work correctly. The chip should behave the same as the buttons in the example. We'll see what exactly is not working when someone starts working on it, but for now, I'm adding the ready-to-take label.

[jaisaichand]

@DiegoAndai Can I debug and work on this?

[DiegoAndai]

@jaisaichand sure, let me know if you need help. Thanks.

[statecs]

Any update? 👍

[jjisabi]

@DiegoAndai Hi Can I work on this?

[DiegoAndai]

Hey @jjisabi, sure! Feel free to work on it. I'll ask you not to open a PR yet, as we're changing to use the next branch. So let's wait until the next branch is created to open it. That should happen in the first half of next week.

@jaisaichand did you ever start working on this?

[shrilsharma]

Hi @DiegoAndai I have resolved this issue but I'm not opening any PR until next branch is created as you have mentioned.

[DiegoAndai]

Hey @shrilsharma, the next branch has been opened. Feel free to create the PR.