[Autocomplete] Cannot read properties of null (reading 'removeAttribute') in syncHighlightedIndexToDOM under StrictMode

[tsgit18]

Duplicates

• I have searched the existing issues and believe this is not a duplicate of an open issue (related but closed/unresolved: [autocomplete] Cannot read property 'removeAttribute' of null in autocomplete input #25273, [Autocomplete] Cannot read properties of null (reading 'focus') #36605)

Steps to reproduce 🕹

Observed in a real app (not yet isolated to a minimal sandbox — happy to build one if useful): an Autocomplete with a custom renderOption, rendered inside <React.StrictMode>, inside a dialog. Interacting with the dropdown (opening it / moving the highlighted option) intermittently throws on mount. The timing lines up with StrictMode's dev-only double-invocation of effects (mount → cleanup → mount), which is what leaves inputRef.current and listboxRef.current in an inconsistent state relative to each other rather than both clearing together.

Current behavior 😯

Intermittent uncaught crash:

TypeError: Cannot read properties of null (reading 'removeAttribute')
    at syncHighlightedIndexToDOM (useAutocomplete.js)

In packages/@mui/material/useAutocomplete/useAutocomplete.js, syncHighlightedIndexToDOM guards against both inputRef.current and listboxRef.current being null, then unconditionally dereferences inputRef.current:

// React can clear refs before pending passive effects run during unmount.
// If both refs are gone, there is no DOM left to sync.
if (inputRef.current == null && listboxRef.current == null) {
  return;
}

// does the index exist?
if (index === -1) {
  inputRef.current.removeAttribute('aria-activedescendant');
} else {
  inputRef.current.setAttribute('aria-activedescendant', `${id}-option-${index}`);
}

If inputRef.current is null while listboxRef.current is still set (the two refs don't necessarily clear in the same commit — the comment directly above even acknowledges refs can clear asymmetrically during unmount), the && guard passes through and the next line throws. This is consistent with the "each ref must be checked independently" root cause discussed on #25273, just resurfaced against the current syncHighlightedIndexToDOM implementation (a later refactor — no existing issue references this function by name).

I recognize #25273 was closed in 2021 with the position that "supporting out-of-order [ref/effect resolution]... doesn't seem worth the extra complexity" for unusual custom-Popper compositions. This report is narrower: it reproduces under plain <Autocomplete> (no custom Popper) purely from React StrictMode's double-invocation of effects, which React's own docs require components to tolerate. So this isn't "user-land assembled it unusually" — it's the library's cleanup path not surviving the React-recommended dev-mode double-invoke contract.

Expected behavior 🤔

syncHighlightedIndexToDOM should guard the inputRef dereference independently of listboxRef, e.g.:

if (inputRef.current != null) {
  if (index === -1) {
    inputRef.current.removeAttribute('aria-activedescendant');
  } else {
    inputRef.current.setAttribute('aria-activedescendant', `${id}-option-${index}`);
  }
}
if (inputRef.current == null && listboxRef.current == null) {
  return;
}

Happy to open a PR with this + a regression test (e.g. mounting under StrictMode and asserting no console error) if that framing is welcome — wanted to check first given the history on #25273.

Context 🔦

Found while building a staff-assignment Autocomplete with a custom renderOption. Confirmed via source inspection that the exact null-guard bug is present in the currently-published 9.2.0. Patched locally with patch-package in the meantime.

Your environment 🌎

• @mui/material: 9.2.0
• React: 19.2.8, rendered inside <React.StrictMode>
• Bundler: Vite (dev server)
• Reproduces in dev (npm run dev), consistent with StrictMode's dev-only double-invocation of effects.

Search keywords:

[ZeeshanTamboli]

Can you provide a live reproduction (without LLM generated code)? It might be that you are not binding the input correctly. We throw a warning (which was added in #25311) when the component does not bind the input ref.

Also, this guard was added in #48617 for React 19.

[zencowork]

You were right — this was a bug in my own code, not Autocomplete. Sorry for the noise.

I had a renderInput that did:

slotProps={{
  input: { ...(params.slotProps?.input ?? {}), startAdornment: ... },
}}

That replaces params.slotProps wholesale instead of spreading it, which silently drops the other slots (htmlInput, etc.) Autocomplete uses to wire its internal inputRef into the actual <input> DOM node.

I isolated it by mounting just that component with the bug reverted, and got exactly the warning from #25311:

MUI: Unable to find the input element. It was resolved to null while an HTMLInputElement was expected.
Instead, Autocomplete expects an input element.
Make sure you have customized the input component correctly.

The role="combobox" was also gone, replaced by a plain textbox. So inputRef.current going null was a direct consequence of my broken ref binding, not a StrictMode double-invoke race — my original theory doesn't hold up. Fixing renderInput to spread params.slotProps first resolves it cleanly and the syncHighlightedIndexToDOM guard is never hit in the broken state.

Closing this out on my end — thanks for pointing me at the right cause instead of taking the report at face value.