Skip to content

fix(forms): avoid crash when a deferred control's container is gone - #71463

Open
RubenPari wants to merge 1 commit into
angular:mainfrom
RubenPari:fix/forms-deferred-registration-null-container
Open

RubenPari wants to merge 1 commit into
angular:mainfrom
RubenPari:fix/forms-deferred-registration-null-container

Conversation

@RubenPari

Copy link
Copy Markdown

PR Checklist

Please check if your PR fulfills the following requirements:

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • angular.dev application / infrastructure changes
  • Other... Please describe:

What is the current behavior?

Issue Number: #69440

NgForm.addControl and NgForm.addFormGroup defer registration to a microtask. If the parent ngModelGroup is destroyed in the same tick in which the control is added, _findContainer() returns null by the time the microtask runs, and container.registerControl(...) throws:

TypeError: Cannot read properties of null (reading 'registerControl')

The matching removeControl/removeFormGroup methods are already null-safe, so the add path was inconsistent.

What is the new behavior?

The deferred registration now returns early when the parent container no longer exists, instead of throwing. The return type of _findContainer() is also corrected to FormGroup | null so the nullable case is visible to the type system.

Regression tests cover both addControl and addFormGroup, asserting that no global error/unhandled rejection is produced when the container is gone.

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

Related to #69440 and the earlier stalled attempt in #69543.

`NgForm.addControl` and `NgForm.addFormGroup` register their directive in
a microtask. If the parent `ngModelGroup` is destroyed in the same tick in
which the control is added, `_findContainer` returns `null` by the time the
microtask runs, and calling `registerControl` on it throws:

    TypeError: Cannot read properties of null (reading 'registerControl')

Guard the deferred registration against a missing container, matching the
already null-safe behavior of `removeControl` and `removeFormGroup`. Also
update the return type of `_findContainer` to `FormGroup | null` so that the
nullable case is reflected in the type system.

Fixes angular#69440
@pullapprove
pullapprove Bot requested a review from crisbeto October 20, 2026 13:50
@ngbot ngbot Bot added this to the Backlog milestone Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant