ng-show/hide is delayed on an element that is animating

[SimplGy]

This is not expected behavior if you're doing a constant animation on something like a loading spinner and just want to hide or show it immediately.

The element was not told to be managed by ng-animate, I just want normal ng-show/hide to happen instantly, and any css animations that happen to be ongoing should be irrelevant, I think.

Fiddle: http://jsfiddle.net/PvS8k/2/

Uncheck "show loader" and note that it takes a few seconds to actually go away.

I think this is a recent change because our loader wasn't sticking in our application before upgrading. I think we were on 1.12 before.

I must be missing something in my understanding of how to use/not use ng-animate, right? In this case I actually want to NOT use it, but if I can use it to ignore this element, that would work too. Definitely surprising behavior though.

[matsko]

ngAnimate is greedy since it assumes that all keyframes/transition code that is active on the element during any of the triggers are there to be animated via ngAnimate. Therefore, in this case, despite .loader having nothing to do with ngShow / ngHide, it is still picked up as a valid animation.

To get around this, simple erase the animation styling when the .ng-animate class is applied on the element.

http://jsfiddle.net/PvS8k/4/

This is a problem with CSS inheritance. If there was a better way to detect styles without having to solely rely on getComputedStyle then these kinds of quirks could possibly be avoided.

[Narretz]

@matsko I think this special case is actually a regression. As you can see in @SimpleAsCouldBe 's plunker, or in this plunker http://plnkr.co/edit/5cfIXfNryNOzK66q9YWL?p=preview, in 1.2.17, the element does not disappear immediately, but in 1.2.16, it does. This is most likely because of 55b2f0e
I think this warrant a little closer inspection; at least there should be a note in the changelog and docs about this.

[SimplGy]

Thanks for the workaround, it does the trick as expected.

Two points. One is specific to ng-show and one is general.

ng-show + infinite animations:

Should an infinite animation really delay an ng-show's hide? I tried counting seconds and it's not always 4 seconds that it waits to hide it. Sometimes its 5 or 7... seems to vary. Also If you flip the checkbox on and off again it never hides. I think there's an actual bug hiding in here somewhere.

Philisophical

As a non-contributor I don't have much say, but maybe opt-out isn't the right strategy for this library. It's just so astoundingly magical to have a JS library react to CSS rules.. If I had to tag elements with ng-animatable I would be much more prepared for this.

[matsko]

@SimpleAsCouldBe yes I've been thinking the same that maybe it might be best to require all animations to have a animate- class prefix such that ngAnimate would then hook into the animations.

Regarding the delay, it's not that there is a delay, it's that ngAnimate cancels out the infinite portion and only runs the animation once. Therefore, when you hide it, it waits for 2s * 1.5 = 3 seconds and then it runs the timeout check and closes of the animation. So it's an unnecessary window of time that shouldn't be there at all--only CSS style detection is highly limited.

[matsko]

@Narretz while the commit you provided may effect this particular example, it doesn't actually have anything to do with the regression. The reason for this is because the .ng-hide styling that was there before the fix applied the display:none value at a different time. But the current fix applies it ONLY after all the animations are done (once the .ng-animate class is removed).

Have a look at the demo below. See how there are two sets of selectors for the .blue class: one with .ng-animate and without it. Despite the .blue class being applied immediately, ngAnimate still thinks an animation is due and will wait for 3s (remember 2s * 1.5) before applying a closing timeout. Normally it would be 2s, but a animationend event is never fired since the actual animation on the element (which is there because of .loader) is infinite and is not-triggered by ng-class (or ng-show for the previous example). So that being said this doesn't get effected due to the prior bug fix.
http://jsfiddle.net/PvS8k/15/

It might be best to make ngAnimate less naive and only animate when animated- is there as a CSS prefix somewhere.

[SimplGy]

I think if you're open to a breaking change like opt-in animation handling, it would create a less surprising developer experience.

Would you be open to prefixing with something angular specific like .ng-animate rather than plain-old .animate?

[tole42]

I have the same Problem:
With angular >=1.2.17 http://jsfiddle.net/9krLr/17/
With angular 1.2.16 everthing is fine: http://jsfiddle.net/EZpQQ/1/

[SimplGy]

@tole42 This is the workaround:

.YourElementClass.ng-animate { -webkit-animation: none 0s; }

[tole42]

Thanks for your help. The workaround is not working :(
What is wrong?
http://jsfiddle.net/9krLr/21/

[SimplGy]

@tole42 Nothing in that fiddle animates, as far as I can see. Is the animation part of the Foundation library? A more direct re-creation case would make this easier to debug. Doesn't look like the same issue to me.