Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Disabling a FormControl wrapped in a ControlValueAccessor fails to disable a parent FormGroup with a FormArray as sibling #62071

Open
@mwaibel-go

Description

@mwaibel-go

Which @angular/* package(s) are the source of the bug?

forms

Is this a regression?

No

Description

The App component contains this FormGroup:

// main.ts (extract)
  protected form = new FormGroup({
    ctl: new FormControl(),
    arr: new FormArray([]),
  });

The FormArray is not realized in the template, but the ctl has an associated ControlValueAccessor implementation in CustomControlComponent:

<!-- app.component.html (extract) -->
<div [formGroup]="form">
  <custom-control formControlName="ctl"></custom-control>
</div>

The custom-control is a bare-bone ControlValueAccessor that simply wraps a FormControl. All the inner FormControl’s events are passed through the CustomControlComponent, and ControlValueAccessor calls on the CustomControlComponent are passed through to the wrapped FormControl.

The CustomControlComponent implements setDisabledState, which calls disable viz. enable on the wrapped FormControl. Notice the {emitEvent: true} in the disable call (not passing an argument makes no difference).

// custom-control.component.ts (extract)
export class CustomControlComponent implements ControlValueAccessor {
  protected ctl = new FormControl();

  public setDisabledState(isDisabled: boolean): void {
    if (isDisabled) {
      this.ctl.disable({ emitEvent: true });
    } else {
      this.ctl.enable();
    }
  }

When disabling the FormGroup, CustomControlComponent::ctl gets disabled as expected. However, the FormGroup gets re-enabled by the event emission. This is visible via the output

Status: enabled but should be disabled

in the AppComponent’s HTML.

Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/stackblitz-starters-dkv8xtfe?file=src%2Fmain.ts

Please provide the exception or error you saw

No Error

Please provide the environment you discovered this bug in (run ng version)

_                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 20.0.0
Node: 20.19.1
Package Manager: npm 10.8.2
OS: linux x64

Angular: 20.0.0
... animations, build, cli, common, compiler, compiler-cli, core
... forms, platform-browser, router

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.2000.0
@angular-devkit/core         20.0.0
@angular-devkit/schematics   20.0.0
@schematics/angular          20.0.0
rxjs                         7.8.2
typescript                   5.8.2
zone.js                      0.15.0

Anything else?

All of the following lead to the FormGroup’s disabling as expected:

  • Removing the FormArray from the FormGroup
  • Replacing the CustomFormControl with a regular ControlValueAccessor (i.e., changing app.component.html, l. 4 with <input type="text" formControlName="ctl">)
  • Preventing the emission of the event (i.e. replacing custom-control.component.ts, l. 28 with this.ctl.disable({ emitEvent: true });)

The bug is also reproducible in

Angular CLI: 19.2.15
Node: 18.20.4
Package Manager: npm 10.9.2
OS: linux x64

Angular: 19.2.14
... common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1902.15
@angular-devkit/build-angular   19.2.15
@angular-devkit/core            19.2.15
@angular-devkit/schematics      19.2.15
@angular/cli                    19.2.15
@schematics/angular             19.2.15
rxjs                            7.8.2
typescript                      5.7.3
zone.js                         0.15.0

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions