[Autocomplete] Cannot read property 'removeAttribute' of null in autocomplete input

I’m running across this issue pretty consistently trying to use the useAutocomplete hook where some aria attributes are trying to be removed from the input. I haven’t been able to narrow down exactly what is triggering it each time. I think the fix might be simpler than spending more time digging into it.

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Cannot read property 'removeAttribute' of null

Steps to Reproduce 🕹

I’ve been able to replicate it by forking the customized hook example and changing it into a controlled component where the autocomplete is always open: https://codesandbox.io/s/material-demo-forked-h1owv?file=/demo.js I have NOT been able to replicate it using the same changes in the useAutocomplete example

Context 🔦

This issue first arose from trying to use the useAutocomplete hook in a popper triggered by a button. Our initial thought was that the input didn’t exist on the page because it lived inside a popper but applying keepMounted also doesn’t fix the issue.

Potential Fix?

Can we apply a check here to see if the inputRef exists first before adding/removing these aria tags? https://github.com/mui-org/material-ui/blob/48bf11343f04db242b69a0a8ceef3c67ac41de4a/packages/material-ui-lab/src/useAutocomplete/useAutocomplete.js#L283

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

[teenguyen]

Wow the answer really was that simple. Thank you so much! This has been a huge blocker for us 😅

[oliviertassinari]

Thanks for bringing this issue to our attention. It’s an interesting downside with exposing headless components. A component structure can force interesting constraints.

Here, the implementation of useAutocomplete is simplified by asking developers to render all its parts with a standard rendering order: all refs resolve before effects. Supporting out of order, would mean having to listen to each ref, to trigger an update once available. It doesn’t seem to be worth the extra complexity.

In your codesandbox, the solution is to create a component for the Popper’s children and use the hook there. It seems simple enough 😃.