ngAnimate addClass/removeClass potential race condition

[sdcooke]

I'm afraid I've so far been unable to create a simple example of this bug, it does happen every time on a larger codebase.

I have an element:

<div ng-class="{ 'navigating': navigating }"></div>

There are CSS animations on the div (from before ngAnimate) and after upgrading to 1.2.3 (from pre-1.2) and adding ngAnimate when the scope variable navigating changes quickly (~100ms) from false to true to false again the "navigating" class remains on the element. So far I've managed to establish this sequence of events:

• performAnimation('addClass', 'navigation'...
• ...
• performAnimation('removeClass', 'navigation'...
• ...
• fireDOMOperation for removeClass
• afterReflow for addClass runs
• fireDOMOperation for addClass

I'm hoping this either rings a bell with someone or someone can point me in the right direction for further debugging.

I'm able to workaround this for now by putting a timeout around the scope variable change.

[Narretz]

@matsko think this is an issue?

[matsko]

Hey guys. So a good place to start to reproduce the bug is to have an animation ready for the element, but change the CSS expression from true -> false -> true (around 100ms each) to see if this race condition pops up?

[sdcooke]

Unfortunately none of the simple cases I write are causing the issue to show, which is odd. I can't think of anything else in our codebase that would be interfering with it. The element that is having the problem is a navigation progress bar (like youtube) so the changes are fired by timers and XHR events.

Do you have any suggestions for debug output I could add that might help track it down? I'm happy to help find the issue (and fix it if it's something I can do) but if it's only me who is seeing this we can leave our workaround in place for now (which is a simple directive to do addClass and removeClass without ngAnimate) until someone else discovers it.

[matsko]

@sdcooke could you try to reproduce the bug somehow in your app and then we can debug it together over hangouts?

[matsko]

Just put together a major fix for class-based animations regarding race-conditions. Could you possibly test out your code using these angularjs JS files (ngRoute is only here convenience):

https://s3.amazonaws.com/angularjs-dev/ng-animate-race-condition-fix/build/angular.js
https://s3.amazonaws.com/angularjs-dev/ng-animate-race-condition-fix/build/angular-animate.js
https://s3.amazonaws.com/angularjs-dev/ng-animate-race-condition-fix/build/angular-route.js

[sdcooke]

That's got it! If I switch from the current stable build to those builds, the bug disappears. Thank you very much!

[jardilio]

FWIW, this fixed my issues as well where the ng-animate classes weren't being removed from the target element and element was stuck in a limbo state when I switched views. Issue arose when I updated from v1.2.2 to 1.2.9, I didn't have any issue with 1.2.2 or with the files linked above.

[matsko]

@jardilio so does 1.2.9 fix the issue or introduce a new one?

[jardilio]

@matsko sorry I didn't see your comment before. Not sure when the issue was introduced, but I did test 1.2.8, 1.2.9 and 1.2.10 which all have the issue. 1.2.2 and the patches you posted all work as intended. In my case, I'm using animations with ngview and animate classes never remove from the target element thus transition won't complete.

[matsko]

@jardilio sorry for the delays. ngAnimate is currently having a rewrite of how it handles class-based animations (nothing will break don't worry) so that they're exactly one to one with standard CSS transitions/animations that are applied by adding and removing a class (think about how animations work without ngAnimate). This is a bit difficult to achieve, but it should hopefully make it into the next release.