ng-cloak elements should not show template binding braces and binding variables during ng-init

[doliver3]

ng-cloak is showing template bindings during ng-init with an alert on Chrome, Firefox, and IE. ng-cloaked areas should never show template bindings braces and variables, and Angular should let the ng-init and template variable interpolation merge complete before showing the elements that are ng-cloaked.

If things go wrong during ng-init, it can be necessary to display a message to the user. It looks bad to still see the template braces and variable bindings behind the message. End users should never see the Angular templates unbound with braces and variable names.

Example shows template bindings appear during ng-init:
http://plnkr.co/edit/cLuIKsdKK9raWbxsmjBG?p=preview

Currently the angular code that removes the hidden styling of the ng-cloaked elements is executed before ng-init executes which is too soon.

CURRENT BEHAVIOR:
/* angular.js 1.1.5 code removes cloaked attribute during the compile phase and compile happens before ng-init which is too soon. Browser immediately renders without the css display:none that the ng-cloak class was providing. */
var ngCloakDirective = ngDirective({
compile: function(element, attr) {
attr.$set('ngCloak', undefined);
element.removeClass('ng-cloak');
}
});

REQUESTED BEHAVIOR:
/* One option for fixing this in the angular.js file is to delay until after the compile phase and ng-init are completed such as the following modification which changes when the ng-cloak class is removed to the link phase which happens after ng-init so the template bindings braces and variables are correctly not visible during ng-init... */
var ngCloakDirective = ngDirective({
link: function (scope, element, attr) {
attr.$set('ngCloak', undefined);
element.removeClass('ng-cloak');
}
});

[fedool]

The same problem happens on mobile browsers. Fix proposed by doliver3 works fine.

[IgorMinar]

This is similar to #5692

The problem is only visible if you use alert, prompt or debugger to force a paint while you are in the middle of the digest.

forcing paints and interrupting the digest loop in this way is uncommon in production and typically happens only during development, in which case the partial rendering of raw template doesn't matter much.

[IgorMinar]

As mentioned in #5692 I can't think of a reproduction that would show an actual problem in production. If you can please open a new issue and post the reproduction.

I'm going to close this as invalid, but if you can provide more info please don't hesitate to open a new issue.

Thanks!

[kevinoid]

Wouldn't the issue also be present if an unhandled exception occurs during during page loading? Although such errors shouldn't happen in production, this issue precludes using ng-cloak to hide the application and display an error message in such an event. Is there another recommended solution for handling such errors gracefully?

[doliver3]

Yes the unhandled exception during page loading issue kevinold mentions is the issue that was causing a huge problem for our application. There was an unhandled exception that occurred that was not detected in testing before deployment to production. When any unexpected unhandled exception occurs on page load, the entire AngularJS page display crumbles into very unprofessional looking confusing, scary double angle bracket placeholders.

With the current implementation of AngularJS with this issue unfixed, the penalty for having an unhandled exception on load when using AngularJS is much worse than for other development frameworks. Instead of having a controlled display of the unhandled error limited to a controlled part of the screen which is typical with other development frameworks, in AngularJS an unexpected, unhandled error on page initialization makes the entire page entirely unreadable by the end user - the screen display is destroyed by displaying the AngularJS bracket syntax.

I would tend to think developers would consider this to be a very large negative for using a development framework such as AngularJS since it exposes very dramatically any unexpected condition the developer did not anticipate to the client end user in a way that the client would visually interpret as catastrophic failure.

Why should AngularJS's default behavior when an unexpected error occur look like catastrophic failure? Isn't controlled, professional error handling by default a hallmark of quality development frameworks? Wouldn't quality error handling be a feature that AngularJS would want to provide to its developer community?