Popper background color does not respect custom theme

[cysabi]

Duplicates

• [X] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Steps to reproduce 🕹

Link to live example:

https://github.com/cq-overlays/dashboard (I have a workaround in overrides.css)

Steps:

1. Create custom theme and overwrite the "grey" color with your own shades

   export const theme = createTheme({
   palette: {
   mode: "dark",
   primary: {
     light: "#008585",
     main: "#00BEBE",
     dark: "#33cbcb",
     contrastText: "#fff",
   },
   secondary: {
     light: "#ab003c",
     main: "#f50057",
     dark: "#f73378",
     contrastText: "#fff",
   },
   grey: {
     50: "#626E84",
     100: "#232c3d",
     200: "#263042",
     300: "#293346",
     400: "#2c374b",
     500: "#2f3a4f",
     600: "#38445a",
     700: "#414d64",
     800: "#4a566e",
     900: "#525f78",
     A700: "#626E84",
     A400: "#707B8F",
     A200: "#7D8799",
     A100: "#8992A2",
     main: "#293346",
     dark: "#2c374b",
   },
   },
   })

2. Create an Autocomplete component

3. Select the component so the popper appears

Current behavior 😯

Currently, the popper has a background color of the default "grey", rather than the grey set in your custom theme:

My custom grey theme is a very blue shade, but as you can see the background color is far more neutral. The custom primary color from my theme is inherited correctly.

Expected behavior 🤔

The background color of this popper should be derived from the custom theme the same way the primary color is.

Context 🔦

I'm attempting to create an autocomplete component, and I have a custom theme.

I would like to add that this is my first time making an issue on this repo so I apologize if I have missed a step. My first assumption was that the popper must have been portal'd outside of the ThemeProvider context, but the dark mode and primary color are inherited fine, so that must not be it.

Your environment 🌎

npx @mui/envinfo

System: OS: Linux 5.10 Ubuntu 20.04.5 LTS (Focal Fossa) Browser: Firefox Binaries: Node: 19.2.0 - ~/.nvm/versions/node/v19.2.0/bin/node Yarn: Not Found npm: 8.19.3 - ~/.nvm/versions/node/v19.2.0/bin/npm Browsers: Chrome: Not Found Firefox: Not Found npmPackages: @emotion/react: ^11.10.5 => 11.10.5 @emotion/styled: ^11.10.5 => 11.10.5 @mui/base: 5.0.0-alpha.116 @mui/core-downloads-tracker: 5.11.7 @mui/material: ^5.11.7 => 5.11.7 @mui/private-theming: 5.11.7 @mui/styled-engine: 5.11.0 @mui/system: 5.11.7 @mui/types: 7.2.3 @mui/utils: 5.11.7 @types/react: ^18.0.27 => 18.0.27 react: ^18.2.0 => 18.2.0 react-dom: ^18.2.0 => 18.2.0 typescript: ^4.9.5 => 4.9.5

[rangoo94]

@LeptoFlare, the AutoComplete component uses Paper underneath for the options list. Depending on what you want to do, I think that you may choose one of these options:

1) Local: Update the Paper in selected AutoComplete

<Autocomplete
  componentsProps={{
    paper: { sx: { bgcolor: "grey.500" } }, // or static color like "#293346"
  }}
/>

2) Global: Update the Paper in AutoComplete (in the whole UI)

export const theme = createTheme({
  // [...]
  components: {
    MuiAutocomplete: {
      styleOverrides: {
        paper: {
          backgroundColor: "#293346",
        },
      },
    },
  },
})

3) Global: Update the Paper background color (in the whole UI)

export const theme = createTheme({
  palette: {
    mode: "dark",
    // [...]
    background: {
        paper: "#293346"
    }
  },
})

I believe that the 2nd or 3rd (global) option will suit you well, given that you want to make this theme global. The background.paper will affect much more components though, so it's less safe.

[cysabi]

thanks for the response! however i'm already using a (less elegant) workaround, and would just like to see this fixed.

[rangoo94]

Unfortunately, I don't think that it may be changed on the MUI side.

The default palette is using static colors (i.e. background.paper is #121212), not the theme color dynamically (like palette.gray).

That change would create more problems, most importantly:

• Every project depending on this behavior (even unaware of that), may look different after the update
• Emotion will not optimize these that well, so dynamic colors will make the MUI slower

[michaldudak]

Indeed, the Paper background does not use the color from the grey palette. @mnajdova, @siriwatknp, @danilo-leal, do you have any idea why this was implemented as such?

Thanks for analyzing the issue, @rangoo94. Your suggestions are valid. @LeptoFlare I'd suggest option 3 if you want all the popups in your application to have a custom background.

[cysabi]

understood! thanks for the explanation

[rangoo94]

@michaldudak, it looks like historically there was an idea to use the grey palette, but it would affect too many components (https://github.com/mui/material-ui/pull/10015). It's a valid point, both for MUI internals and external libraries.

Putting that aside, I think that the current solution makes sense:

• Semantically, it is distinctive from the grey palette (it's using #ffffff for light and #121212 for dark mode, and they don't correlate together)
• As the Paper is a base container, components may want to "inherit" its background color
  • Example: NativeSelectInput is using it for styling dropdown options, and couldn't use Paper directly in optgroup)

It may be worth to consider merging background.paper and background.default together though - looking at the code, it feels like these are used alternatively anyway (while shouldn't be).