App freezes when using a directive that transcludes ng-message

[robianmcd]

I'm trying to create a directive that contains some common css classes and hide/show logic that I use for all my ng-messages. it looks like this

var StandardMessagesComponent = function() {

}

angular.module('myApp').component('standardMessages', {
    controller: StandardMessagesComponent,
    controllerAs: 'ctrl',
    templateUrl: 'standardMessages.html',
    transclude: true,
    bindings: {
        form: '<',
        field: '@'
    }
});

<ng-messages for="ctrl.form[ctrl.field].$error" role="alert" class="standard-messages"
             ng-if="ctrl.form[ctrl.field].$error && (ctrl.form.$submitted || ctrl.form[ctrl.field].$touched)"
>
    <ng-transclude></ng-transclude>
</ng-messages>

It is causing my app to freeze when the following is true:
-there is a validation error causing one of the ng-messages to be shown
-there are multiple ng-message elements
-The user navigates to another page

The following plunkr reproduces the issue: https://plnkr.co/edit/Qi2JQ4RioAOxZG98uCou?p=preview
To crash the app click the input and then click the "other page" link.

I'm using Angular 1.5, angular-messages 1.5, and ui-router 0.2.18. This issue exists in Chrome and Firefox but works fine in IE11 (although it freezes for a second)

[gkalpak]

FWIW, this is not related to uiRouter. It happens with any structural directive (example with ngIf).

Without looking too much into it, there seems to be an infinite loop because the ngMessage is removed, which causes a reRender() which somehow re-inserts the ngMessage element (not sure why this only happens in the presence of ngTransclude inside standardMessages).
It also happens only if the first ngMessage is currently shown.
BTW, it was introduced in 1.4.0-beta.5 (i.e. it works fine until 1.4.0-beta.4).

Ugly, temp, hackish work-around: PRepend a dummy ngMessage (that will never be shown) :(

[gkalpak]

So, since this broke in v1.4.0-beta.5 and since it's related to angular-message@v1.4.0-beta.5, it must be c9a4421.

[robianmcd]

@gkalpak thanks, good to know there is a temporary workaround