Description
The $CoreAnimateCssProvider's implementation of the runner.done() function behavior doesn't match the behavior that is documented in the ngAnimate.$animateCss documentation.
The ngAnimate.$animateCss documentation says:
runner.done() vs runner.then()
It is documented that
animation.start()will return a promise object and this is true, however, there is also an additional method available on the runner called.done(callbackFn). The done method works the same as.finally(callbackFn), however, it does not trigger a digest to occur. Therefore, for performance reasons, it's always best to userunner.done(callback)instead ofrunner.then(),runner.catch()orrunner.finally()unless you really need a digest to kick off afterwards.
The $CoreAnimateCssProvider'srunner.done() implemenation takes the first argument as a flag indicating if the promise should be canceled or not. The callback passed in will never be called:
done: function(cancel) {
this.defer && this.defer[cancel === true ? 'reject' : 'resolve']();
},Because the $CoreAnimateCssProvider links to the ngAnimate.$animateCss documentation, I would expect the $CoreAnimateCssProvider to behave the same way.
This is causing bugs for other projects that that allow users to opt-in to animations and depend on the done() method.