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 use runner.done(callback) instead of runner.then(), runner.catch() or runner.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.