bug(mat-chip-grid): mat-chip-grid marks FormControl as dirty on blur without actual value changes

[Emil-Blomquist]

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

No response

Description

When using mat-chip-grid bound to a FormControl, the control is marked as dirty when the user focuses on the input field and then blurs away, even when no chips are added or removed and the value remains unchanged.

Reproduction

StackBlitz link: https://stackblitz.com/edit/2za91ztq?file=src%2Fexample%2Fchips-form-control-example.html
Steps to reproduce:

1. Click into the input field
2. Click away (blur) without typing anything or adding any chips
3. Check the FormControl's dirty state - it will be true even though no value changes occurred

Expected Behavior

The FormControl should only become dirty when the actual value changes (chips added/removed), not merely from focus/blur interaction.

Actual Behavior

The FormControl becomes dirty after focus/blur interaction even when no chips are added or removed and the value remains unchanged.

Environment

• Angular: 20.1.0
• CDK/Material: 20.1.0
• Browser(s): Chrome
• Operating System (e.g. Windows, macOS, Ubuntu): Mac

[crisbeto]

There are a couple of issues here:

1. In your setup the value of the form control is ['angular'], but you're rendering out 3 more chips. This means that it'll always be considered different on blur. Generally the form control should match what's on the screen.
2. Even if the first issue was resolved, we'd still mark the control as dirty because we always emit the change event on blur.

The second issue can be resolved on our end.

[Emil-Blomquist]

Ah, sorry, my bad! I essentially copied the "chip and form control" example from the Angular Material website, overlooking the additional three chips. Thus, I completely agree with your first point, and the issue at hand is your second point. Thanks for clearing that up! :)

[crisbeto]

I took a stab at this in #31607. It's a bit hard to land internally, because some apps depend on the current behavior and will have to be reworked. I don't time to look into all of them, but #31607 can be used as a reference if anybody else wants to take it on.