Repository navigation
[autocomplete] Backspace, Delete and the chip's own delete icon clear a single value rendered with renderValue despite disableClearable #49248
Description
Steps to reproduce
Steps:
- Open this link to live example: https://codesandbox.io/s/jy22jp (preview: https://jy22jp.csb.app/) (required)
- The Autocomplete is single-value, has disableClearable, and renders its value "René" as a chip through renderValue.
- Either: (a) click in the input then press Backspace, (b) click in the input then press Delete, or (c) click the chip's own delete (x) icon.
Current behavior
All three actions clear the value: onChange is called with null and reason "removeOption", and the chip disappears, although disableClearable is set.
Expected behavior
With disableClearable, none of these three actions clear the value: Backspace and Delete on an empty input, and the chip's own delete icon, all leave the single rendered value in place, as the hidden clear indicator already does, and as the input-clearing path already does.
Context
In useAutocomplete, three call sites remove the single renderValue value without reading disableClearable, while the input-clearing guard does:
- Backspace:
- Delete:
- The chip's own delete icon (handleSingleItemDelete, wired via getItemProps):
material-ui/packages/mui-material/src/useAutocomplete/useAutocomplete.js
Lines 1302 to 1306 in fcd2962
- Clear on empty input, which does honor it:
Adding !disableClearable to these three conditions would align them with the input-clearing path. We render required single selects as chips, and currently guard Backspace/Delete ourselves with an onKeyDownCapture and hide the chip's delete icon with CSS; neither is needed once the library itself honors disableClearable here.
Your environment
npx @mui/envinfo
Browsers: Chromium (via CodeSandbox preview)
npmPackages:
@mui/material: 9.4.0 (latest)
react: latest
react-dom: latest
Reproduced with both Backspace and Delete.
Search keywords: disableClearable renderValue backspace delete chip single handleSingleItemDelete
Activity
ZeeshanTamboli commentedon Sep 30, 2026
Thanks for reporting.
ZeeshanTamboli commentedon Sep 30, 2026
disableClearablealso doesn't work withmultiplemode when usingrenderValueor without it: https://codesandbox.io/p/sandbox/mui-autocomplete-disableclearable-backspace-forked-qh8ndt. What do you think about this @pcourant ?I think
disableClearableis meant to only remove the "Clear icon", but I don't think that works well in case ofrenderValue(single/multiple) and onlymultiplemode. It works only for single select mode.ZeeshanTamboli commentedon Oct 1, 2026
@pcourant Also, does
readOnlyprop work for your use case?pcourant commentedon Oct 1, 2026
readOnlydoesn't fit: the field is required, not frozen. The user can pick another option, but must never leave it empty.readOnlykeeps the popup closed (L246).Agreed on
multiple: removing a chip is expected there, and I'm not asking to change it.Single value +
renderValuestill looks like a bug to me:disableClearable, AutocompleteValue isNonNullable, yet these paths callonChange(null);So #49264, scoped to single-value
renderValue, looks right to me.silviuaavram commentedon Oct 5, 2026
Hi! I don't think this use case is valid. From the docs, disableClearable:
If true, the input can't be cleared.And we're fulfilling that promise, we don't allow you to clear the input via the Clear button.What you're expecting is the
valuenot being cleared. That's something else. Value, when usingrenderValue, in your case, has nothing to do with theinput. It's not the input's value, it's another element (the chip), the input is empty whenever a value is selected and visible. Your use case sounds more like "whenever you pick a value, the most you can do is change it, you cannot unpick a value". And for this use case, you should be able to do it with our API. Just not withdisableClearablewhich clearly has a different meaning and use case.github-actions commentedon Oct 5, 2026
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.
@pcourant 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.