bug(components): After upgrading from Angular 19 to 20, the bg of many components became transparent

[doucsag]

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

19

Description

I upgraded my app to angular 20 and material 20 with M2. After the upgrade, lots of components became transparent or color-less like dropdowns, buttons etc:

These are screenshots from the Stackblitz provided.

Reproduction

StackBlitz link: https://stackblitz.com/~/github.com/doucsag/angular-20-material-issue
Steps to reproduce:

1. Click on a dropdown (It might look like its working normally if there is nothing behind it, but its transparent)

Expected Behavior

Should be white and not transparent.

Actual Behavior

Is transparent.

Environment

• Angular: 20.1.4
• CDK/Material: 20.1.4
• Browser(s): Chrome, Brave
• Operating System: Windows

[Magnus-Fidelis]

I have the same issue,did you found a workaround ?

[benelliott]

I believe this will be due to the theming changes that were made in version 20.1.0 - perhaps you could try downgrading to 20.0.6 or working through the changes that were in that release?

https://github.com/angular/components/blob/main/CHANGELOG.md#2010-metal-brownie-2025-07-09

There have been some internal mapping changes in Material 2 theme config maps generated by mat.define-light-theme and mat.define-dark-theme.

I am currently hitting these myself - unsure why this change was released as a minor version update as to my knowledge this theme config was always implicitly part of the public API.

[benelliott]

I've done some more debugging - what has specifically changed is that core styles (such as the background color for menu overlays) are now pulled from a _mat-system key that sits at the top level of the theme definition.

Code that manually assembled the theme map (i.e. specified colors) will no longer work because it isn't providing these system colors.

In your code for example, you are implicitly clearing the _mat-system config when you overwrite $light-theme. You can restore it, e.g. by doing

  /* Merge the custom base colors with the generated themes */
  $light-theme-colors: map.merge(map.get($light-theme, color), $light-base);
  $light-theme: map.merge(
    (
      color: $light-theme-colors,
      _mat-system: map.get($light-theme, _mat-system)
    ),
    $light-theme-colors
  );

  $dark-theme-colors: map.merge(map.get($dark-theme, color), $dark-base);
  $dark-theme: map.merge(
    (
      color: $dark-theme-colors,
      _mat-system: map.get($light-theme, _mat-system)
    ),
    $dark-theme-colors
  );

However the underscore in _mat-system really emphasises that it's not a public API and could change in the future.

I'm not sure if manually building a theme object like this was officially supported before (my recollection is that it was at one point) but it won't work as easily now.

[benelliott]

I think I have found at least one case where this has broken a documented, public API. The M2 theme guide lists out all tokens provided in the background and foreground palettes of your theme: https://material.angular.dev/guide/material-2-theming#reading-color-values

It also says you can read them using the get-theme-color function, e.g.

$disabled-button-background: mat.get-theme-color($theme, background, disabled-button)

However I don't think these background palettes are used by components such as button any more, as they use this new _mat-system instead - and the colours are in fact different between what comes out of that get-theme-color call and the actual value seen on the element:

[andrewseguin]

Duplicate of #31538

Also check out the CHANGELOG for this: https://github.com/angular/components/blob/main/CHANGELOG.md#2010-metal-brownie-2025-07-09

The internal setup of the theme config was not part of the public API and has changed several times over the years. The API for getting the foreground/background palette colors still works as expected, but that was meant for reading, not overriding. In fact our use of those palettes was pretty haphazard, e.g. there was no distinction between card and dialog colors, which were the same but used interchangeably in the implementation.

For a workaround, here's a comment I left in the other issue:

If you want to continue with another solution that is at risk of changing anytime - you can continue to change the values in the theme config. There's a top-level map _mat-system that is used for the M2 component theme styles instead of the background/foreground colors

[benelliott]

Hi @andrewseguin ,

The API for getting the foreground/background palette colors still works as expected, but that was meant for reading, not overriding.

What I was getting at here is that reading, say, the "disabled button" background colour from the theme config in the method advised by the docs no longer returns the actual value that is used in the DOM (see screenshot).

Thanks

[andrewseguin]

Gotcha - that's true about the button, which now matches the colors defined in the latest M2 spec (on-surface at 38%). We decided not to update the foreground/background palettes to avoid disruption but I can see how that can be confusing since it says it should match.

The tricky thing here is that those background/foreground palettes were used very inconsistently across the components, and often the wrong value and/or unused. For example, neither raised-button or selected-disabled-button were correct or used by the button.

What we're trying to aim for soon is giving better parity with the M3 setup by making it easy to add CSS variables to read these values, like var(--mat-sys-primary) or var(--mat-sys-surface). These will be the actual referenced colors used by the components.

There's still the open design about how to properly override these in the theme however