You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Autocomplete's listbox Paper defaults to elevation 1, while Select/Menu's Popover defaults to elevation 8 — inconsistent shadow between components with the same UI role #48933
Compare the box-shadow of the open Select's Menu Paper vs. the open Autocomplete's listbox Paper
Current behavior
The Select's Menu Paper defaults to `elevation={8}
The Autocomplete's listbox Paper renders with no explicit elevation passed in paperProps, so it falls back to Paper's own default of elevation={1}:
Two components that serve the same UI purpose — a floating list of selectable options anchored to a field — render with visibly different shadow depth by default.
Expected behavior
Either:
Autocomplete's listbox Paper should default to the same elevation as Select/Menu's Popover (8), since both are "floating option list" surfaces anchored to a field
and are commonly used interchangeably in the same UI (e.g. a filter bar mixing plain Selects and Autocompletes), or
If the difference is intentional (e.g. Autocomplete is meant to read as a lighter-weight surface), this should be documented, so it's clear the mismatch has to be
fixed manually via slotProps={{ paper: { elevation: 8 } }} when visual parity with Select is wanted.
Context
No response
Your environment
Search keywords: autocomplete elevation, autocomplete shadow, autocomplete paper elevation, select menu popover elevation, autocomplete vs select shadow
@silviuaavram
Thanks for your response - while the expected behavior is detailed in the description, there are two options proposed:
Either:
Autocomplete's listbox Paper should default to the same elevation as Select/Menu's Popover (8), since both are "floating option list" surfaces anchored to a field
and are commonly used interchangeably in the same UI (e.g. a filter bar mixing plain Selects and Autocompletes), or
If the difference is intentional (e.g. Autocomplete is meant to read as a lighter-weight surface), this should be documented, so it's clear the mismatch has to be
fixed manually via slotProps={{ paper: { elevation: 8 } }} when visual parity with Select is wanted.
So, was looking for guidance / confirmation on which of the two proposals is recommended ?
Will then go ahead and raise PR for the recommended approach.
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.
@trabati 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.
Activity
silviuaavram commentedon Aug 6, 2026
So there's a workaround. We should decide if we want to go for consistency and do the change.
silviuaavram commentedon Aug 7, 2026
This is a breaking change. Might consider it for the next major.
namansancheti commentedon Aug 28, 2026
@silviuaavram
I would like to work on this - can you please clarify the
Expected behavior?Will then go ahead and raise PR.
silviuaavram commentedon Aug 31, 2026
The expected behavior is detailed in the description.
namansancheti commentedon Aug 31, 2026
@silviuaavram
Thanks for your response - while the expected behavior is detailed in the description, there are two options proposed:
So, was looking for guidance / confirmation on which of the two proposals is recommended ?
Will then go ahead and raise PR for the recommended approach.
namansancheti commentedon Sep 2, 2026
@silviuaavram
Can you please assign this issue to me ?
Will raise PR for both the approaches (update default elevation, and Docs update) for your review.
silviuaavram commentedon Sep 7, 2026
@namansancheti you can go ahead, just keep in mind that the changes won't land immediately, since they are breaking changes.
namansancheti commentedon Sep 7, 2026
@silviuaavram
Thank you for confirming 👍
I have raised the PR - please review, when you get a chance:
#49110
Happy to make required changes (if any).
github-actions commentedon Oct 7, 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.
@trabati 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.