fix($animate): ensure that parallel class-based animations are all eventually closed

[matsko]

When multiple classes are added/removed in parallel then $animate only closes off the
last animation when the fallback timer has expired. Now all animations are closed off.

Fixes #7766

[mary-poppins]

Mary Poppins needs to take a vacation.

[petebacondarwin]

@matsko - the code and test look good but on the plunker there is a weird slight delay between the loading message disappearing and the actual button disappearing. I don't see why that should be happening. Any thoughts?

[danxshap]

I'm seeing the delay as well. My expectation would be that since both $scope.buttonVisible and $scope.loading are set to false simultaneously, you shouldn't be able to see the button label change back before the entire button disappears.

[matsko]

The delay is there since the ngShow animation commences just after the $timeout is done. The ngShow animation sets the space for the transition since it is applied globally to all animations that share the .smooth-hover-button class. So this works as expected.

[danxshap]

@matsko are you saying that the transition I have in the .smooth-hover-button class is affecting ngShow? I would think that this wouldn't be the case since I have transition-property: background-color; in that class, so shouldn't the transition only apply to background color changes, which ngShow does not involve?

[matsko]

@danxshap this works as expected. ngAnimate is not smart enough to deduce a transition that will take place based on the transition-property since getComputedStyle still returns the transition-duration value when the ngShow hook kicks off.

Notice how cancelling out the transition for ng-hide makes this work: http://plnkr.co/edit/7UhX1HBjnRyfAmOGWRwW?p=preview

[danxshap]

Ugh, some Github issue and my comment showed up twice, so I deleted 1 and now they're both gone!

Rewriting...

@matsko I'll admit I don't have an intimate understanding of the ngAnimate source (e.g. how getComputedStyle works), but I will say that in my opinion this would be a "gotcha" for anyone upgrading from 1.2 (note the delay does not happen here: http://plnkr.co/edit/je2xLV9kMfgFxrSFeW8A?p=preview)

From my perspective as an Angular user: I have a button which I've put a CSS transition on so that the background color changes smoothly on hover. Now I simply want to hide the button with Angular.

As you showed in your example, now I'll also have to remember to set the transition-duration property to 0 on my element when the ng-animate class is applied. I guess this isn't that big of a deal now that I'm aware of the issue, but I could definitely see this tripping up quite a few people.

My 2 cents.

[matsko]

Yes this is one of those unfortunate side-effects of relying too much on CSS. But sadly getComputedStyle is all we have and there is no way to detect to see if a transition actually kicked off or not without doing a deep copy of every style on getComputedStyle.

I've been searching for an answer for quite some time:
https://stackoverflow.com/questions/22571651/detecting-if-a-transition-takes-off

[danxshap]

It would be cool if I could put a class on my element like ng-dont-animate or something and then ngAnimate would just leave it alone. At a high level, sounds like that would be a useful solution :)

[matsko]

There's a provider flag called $animateProvider.classNameFilter that does the inverse of that.

[danxshap]

Nice, thanks for the tip! If you're not using ngAnimate for that many other elements on the page, that could definitely be a solution here. For anyone who stumbles across this, here's a quick demo (assuming you've checked out the examples above): http://plnkr.co/edit/13WQJe3p4wpHaPGNJRwc?p=preview

[matsko]

Very nice. Also (finally) this pull request came out to green. Merging this in now.

[matsko]

Merged. Landed as f07af61

[matsko]

Thank you @danxshap for all the help on finding this bug.

[danxshap]

Anytime!