[FocusTrap] Inputs in shadow dom not selectable (since 7.3.6)

[Maverick283]

Steps to reproduce

Steps:

1. Open this link to live example: https://codesandbox.io/p/devbox/elegant-keller-pxswkw
2. Click on "open modal"
3. Attempt to change the value of the input field in the modal

Current behavior

The input field is not really selectable and the input value can not be changed.

It seems as if the focus is lost right after it is selected.

Expected behavior

The input field should be selectable, even if it was rendered within a shadow dom.

Context

Where does this become an issue?

Some UI libraries have the (exceptionally bad) concept to adjust styling and behavior after the intial DOM has loaded using a script to replace stuff with shadow roots. In our case, this is a corporate library that we must use to display e.g. input fields.

We're using MUI as that library is not providing layouts/patterns/components for everything, and the remaining stuff is implemented with MUI.

This automatically introduces some mix of components, e.g. we want a Popup that has a text box. The library has text fields (input) but it does not provide a way to create a popup.

In the codesandbox mentioned above, this is "simulated" - we use <Modal/> for the Popup implementation, and a <input/> for the text field. Like with the library, the <input/> is placed in a shadow DOM.

With that setup, changing the text of the input is not possible anymore.

Culprit: v7.3.6

I believe that I've pinpointed the issue down to these two commits:
5536c15
15ff395

Specifically, the FocusTrap seems to be interfering here.

I strongly believe that the FocusTrap should not interfere with non-MUI elements in a way, that renders them dysfunctional.

Using the same code, but with v7.3.5, the code from the codesandbox works.
If you try it out, make sure to delete 'node_modules', as the ^7.3.5 notation for the mui/utils package would allow npm to keep the 'faulty' implementation.

Your environment

npx @mui/envinfo

  Issue exists (at least) in chrome and firefox

  System:
    OS: Linux 6.1 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
  Binaries:
    Node: 20.19.5 - /usr/local/bin/node
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    @emotion/react:  11.14.0 
    @emotion/styled: ^11.14.1 => 11.14.1 
    @mui/core-downloads-tracker:  7.3.6 
    @mui/material: 7.3.6 => 7.3.6 
    @mui/material-nextjs: 7.3.6 => 7.3.6 
    @mui/private-theming:  7.3.6 
    @mui/styled-engine:  7.3.6 
    @mui/system:  7.3.6 
    @mui/types:  7.4.9 
    @mui/utils:  7.3.6 
    @types/react: 18.2.25 => 18.2.25 
    react: 18.2.0 => 18.2.0 
    react-dom: 18.2.0 => 18.2.0 
    typescript: 5.2.2 => 5.2.2 

Search keywords: input shadow dom selectable

[ZeeshanTamboli]

Thanks for the reproduction.

This issue occurs because the input element lives inside a Shadow DOM that is not part of the Modal's DOM subtree. Since v7.3.6, the FocusTrap became Shadow-DOM aware via getActiveElement, but the containment check it uses (root.contains(...)) is still Shadow-DOM unaware. As a result, the trap thinks focus has escaped and immediately pulls it back.

You can work around this by adding:

<Dialog disableEnforceFocus ...>

(or on Modal / Popover, depending on the component you use). See https://codesandbox.io/p/devbox/mui-7-3-6-input-shadow-root-issue-forked-x6nm3c

This prevents FocusTrap from forcibly re-capturing focus and allows the Shadow-DOM input to behave normally.

---

Before 7.3.6:

• activeElement was just doc.activeElement, usually the host (#host) or some element the trap considered "inside".

• rootElement.contains(doc.activeElement) returned true.

So FocusTrap did not try to steal focus back and everything appeared to “work” (by accident).

---

Maybe the solution is to update the FocusTrap logic so that the "is focus inside the trap?" check becomes Shadow-DOM aware as well i.e, climbing through the composed tree instead of relying on Node.contains(). This would allow Shadow-DOM-hosted inputs to work without disabling focus enforcement.