You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
If ng-model is used within a form and toggled with ng-if and $setValidity is called on the ngModelController, then a memory leak occurs.
Specifically, the $setValidity call in ngModel (line 3172) adds a validity entry to the parent form controller that keeps a reference to the ngModelController. There's nothing in place to remove this entry if that controller gets destroyed, so these references stick around. Worse, the $setValidity call is added to the ngModelController by creating a closure that wraps the ngModel's element, which can result in leaking quite a bit of memory in complex applications.
This plunker demonstrates the issue by printing out the number of ngModelController references maintained by the form controller each time you toggle a form input off/on.
The text was updated successfully, but these errors were encountered:
If
ng-model
is used within a form and toggled withng-if
and$setValidity
is called on thengModelController
, then a memory leak occurs.Specifically, the
$setValidity
call inngModel
(line 3172) adds a validity entry to the parent form controller that keeps a reference to thengModelController
. There's nothing in place to remove this entry if that controller gets destroyed, so these references stick around. Worse, the$setValidity
call is added to thengModelController
by creating a closure that wraps thengModel
's element, which can result in leaking quite a bit of memory in complex applications.This plunker demonstrates the issue by printing out the number of
ngModelController
references maintained by the form controller each time you toggle a form input off/on.The text was updated successfully, but these errors were encountered: