Animations should not cancel parent animations #11975

jonrimmer · 2015-05-29T09:30:57Z

1.4 has broken some important animations in my application. Apparently this is because ng-enter animations have been modified to cancel running ng-class animations on their parents, for some insane reason?

I have a container element with a router ui-view nested inside it. The container has an ng-class that sets 'active' on the container when a particular route becomes active, which is then used to slide the container into view. The ui-view element itself has an ng-enter animation that transitions its opacity.

In 1.3 this all worked perfectly. In 1.4 it is broken, because the framework apparently thinks that, because I'm animating the opacity of one element, I mustn't want the position animation—that I have explicitly specified—on its parent to run. In what universe is this desirable behaviour?

Narretz · 2015-05-29T12:41:59Z

Yesh, this happened in c8700f0

It does seem very limiting. @matsko do you have an idea how this can be remedied?

matsko · 2015-06-09T17:20:13Z

Yes I'm working on a full fix. It should be ready towards the end of the week and in time for 1.4.1

…losed by their children This fix ensures that a structural child animation will never close a parent class based early so that the CSS classes for the child are ready for it to perform its CSS animation. The reasoning for the past for this was because their is a one frame delay before the classes were applied. If a parent and a child animation happen at the same time then the animations may not be picked up for the element since the CSS classes may not have been applied yet. This fix ensures that parent CSS classes are applied in a synchronous manner without the need to run a one RAF wait. The solution to this was to apply the preparation classes during the pre-digest phase and then apply the CSS classes right after with a forced reflow paint. BREAKING CHANGE: CSS classes added/removed by ngAnimate are now applied synchronously once the first digest has passed. The previous behavior involved ngAnimate having to wait for one requestAnimationFrame before CSS classes were added/removed. The CSS classes are now applied directly after the first digest that is triggered after `$animate.addClass`, `$animate.removeClass` or `$animate.setClass` is called. If any of your code relies on waiting for one frame before checking for CSS classes on the element then please change this behavior. If a parent class-based animation, however, is run through a JavaScript animation which triggers an animation for `beforeAddClass` and/or `beforeRemoveClass` then the CSS classes will not be applied in time for the children (and the parent class-based animation will not be cancelled by any child animations). Closes angular#11975

matsko · 2015-06-30T21:53:33Z

This PR should fix it: #12248

…n animated This fix ensures that for both `$animateCss` and `$animate` capture the error when a class-based animation takes place where the element is removed from the parent element sometime before or during the preparation stages the animation. Closes angular#11975

…n animated This fix ensures that for both `$animateCss` and `$animate` capture the error when an animation takes place where the element is removed from the parent element sometime before or during the preparation stages of the animation. Closes angular#11975 Closes angular#12338

…losed by their children This fix ensures that a structural child animation will never close a parent class based early so that the CSS classes for the child are ready for it to perform its CSS animation. The reasoning for the past for this was because their is a one frame delay before the classes were applied. If a parent and a child animation happen at the same time then the animations may not be picked up for the element since the CSS classes may not have been applied yet. This fix ensures that parent CSS classes are applied in a synchronous manner without the need to run a one RAF wait. The solution to this was to apply the preparation classes during the pre-digest phase and then apply the CSS classes right after with a forced reflow paint. BREAKING CHANGE: CSS classes added/removed by ngAnimate are now applied synchronously once the first digest has passed. The previous behavior involved ngAnimate having to wait for one requestAnimationFrame before CSS classes were added/removed. The CSS classes are now applied directly after the first digest that is triggered after `$animate.addClass`, `$animate.removeClass` or `$animate.setClass` is called. If any of your code relies on waiting for one frame before checking for CSS classes on the element then please change this behavior. If a parent class-based animation, however, is run through a JavaScript animation which triggers an animation for `beforeAddClass` and/or `beforeRemoveClass` then the CSS classes will not be applied in time for the children (and the parent class-based animation will not be cancelled by any child animations). Closes angular#11975

…losed by their children This fix ensures that a structural child animation will never close a parent class based early so that the CSS classes for the child are ready for it to perform its CSS animation. The reasoning for the past for this was because their is a one frame delay before the classes were applied. If a parent and a child animation happen at the same time then the animations may not be picked up for the element since the CSS classes may not have been applied yet. This fix ensures that parent CSS classes are applied in a synchronous manner without the need to run a one RAF wait. The solution to this was to apply the preparation classes during the pre-digest phase and then apply the CSS classes right after with a forced reflow paint. BREAKING CHANGE: CSS classes added/removed by ngAnimate are now applied synchronously once the first digest has passed. The previous behavior involved ngAnimate having to wait for one requestAnimationFrame before CSS classes were added/removed. The CSS classes are now applied directly after the first digest that is triggered after `$animate.addClass`, `$animate.removeClass` or `$animate.setClass` is called. If any of your code relies on waiting for one frame before checking for CSS classes on the element then please change this behavior. If a parent class-based animation, however, is run through a JavaScript animation which triggers an animation for `beforeAddClass` and/or `beforeRemoveClass` then the CSS classes will not be applied in time for the children (and the parent class-based animation will not be cancelled by any child animations). Closes angular#11975 Closes angular#12276

…losed by their children This fix ensures that a structural child animation will never close a parent class based early so that the CSS classes for the child are ready for it to perform its CSS animation. The reasoning for the past for this was because their is a one frame delay before the classes were applied. If a parent and a child animation happen at the same time then the animations may not be picked up for the element since the CSS classes may not have been applied yet. This fix ensures that parent CSS classes are applied in a synchronous manner without the need to run a one RAF wait. The solution to this was to apply the preparation classes during the pre-digest phase and then apply the CSS classes right after with a forced reflow paint. BREAKING CHANGE: CSS classes added/removed by ngAnimate are now applied synchronously once the first digest has passed. The previous behavior involved ngAnimate having to wait for one requestAnimationFrame before CSS classes were added/removed. The CSS classes are now applied directly after the first digest that is triggered after `$animate.addClass`, `$animate.removeClass` or `$animate.setClass` is called. If any of your code relies on waiting for one frame before checking for CSS classes on the element then please change this behavior. If a parent class-based animation, however, is run through a JavaScript animation which triggers an animation for `beforeAddClass` and/or `beforeRemoveClass` then the CSS classes will not be applied in time for the children (and the parent class-based animation will not be cancelled by any child animations). Closes #11975 Closes #12276

matsko · 2015-07-20T21:24:51Z

This is now fixed in master.

jonrimmer · 2015-07-21T08:12:50Z

👍

jonrimmer · 2015-07-21T08:58:25Z

Perhaps I am missing something, but this still does not seem to be working in 1.4.3.

Take a look at the following Plunkr, which shows a simplified version of the kind of thing I am doing. I'm using ng-class to toggle an "active" class on a sidebar depending on the current ui-router state.

http://plnkr.co/edit/xDMuBc?p=preview

In 1.3.17 it works. If you change the version to 1.4.3, it doesn't. Is there some other change between the versions that is breaking this that I'm unaware of?

Narretz · 2015-07-21T09:05:46Z

@jonrimmer the fix is not in a release yet. It's in master so you should test with the current snapshot. It will be part of 1.4.4

jonrimmer · 2015-07-21T09:11:43Z

Ah, OK, thanks. I was going by the changelog, which is showing this as fixed in 1.4.3. Thanks!

…n animated This fix ensures that both `$animateCss` and `$animate` swallow the error when an animation takes place in the sitation that the element is removed from the parent element sometime before or during the preparation stages of the animation. Closes angular#11975 Closes angular#12338

…losed by their children This fix ensures that a structural child animation will never close a parent class based early so that the CSS classes for the child are ready for it to perform its CSS animation. The reasoning for the past for this was because their is a one frame delay before the classes were applied. If a parent and a child animation happen at the same time then the animations may not be picked up for the element since the CSS classes may not have been applied yet. This fix ensures that parent CSS classes are applied in a synchronous manner without the need to run a one RAF wait. The solution to this was to apply the preparation classes during the pre-digest phase and then apply the CSS classes right after with a forced reflow paint. BREAKING CHANGE: CSS classes added/removed by ngAnimate are now applied synchronously once the first digest has passed. The previous behavior involved ngAnimate having to wait for one requestAnimationFrame before CSS classes were added/removed. The CSS classes are now applied directly after the first digest that is triggered after `$animate.addClass`, `$animate.removeClass` or `$animate.setClass` is called. If any of your code relies on waiting for one frame before checking for CSS classes on the element then please change this behavior. If a parent class-based animation, however, is run through a JavaScript animation which triggers an animation for `beforeAddClass` and/or `beforeRemoveClass` then the CSS classes will not be applied in time for the children (and the parent class-based animation will not be cancelled by any child animations). Closes angular#11975 Closes angular#12276

poshest · 2015-08-13T08:24:56Z

Is this the same issue? I have a Plunkr where the animate on the outer div with ng-show doesn't work in 1.4.x because of the presence of the child ng-if. It works by either

removing the ng-if, or
downgrading to <1.3.x Angular file versions

Haven't tried latest 1.4.4 candidate yet - not sure how to since the latest code is not yet on the CDN or Angular. Is 1.4.4 near release?

poshest · 2015-08-17T07:55:53Z

In answer to my question, 1.4.4 just released does fix my problem too. Must have been the same or similar problem.

…losed by their children This fix ensures that a structural child animation will never close a parent class based early so that the CSS classes for the child are ready for it to perform its CSS animation. The reasoning for the past for this was because their is a one frame delay before the classes were applied. If a parent and a child animation happen at the same time then the animations may not be picked up for the element since the CSS classes may not have been applied yet. This fix ensures that parent CSS classes are applied in a synchronous manner without the need to run a one RAF wait. The solution to this was to apply the preparation classes during the pre-digest phase and then apply the CSS classes right after with a forced reflow paint. BREAKING CHANGE: CSS classes added/removed by ngAnimate are now applied synchronously once the first digest has passed. The previous behavior involved ngAnimate having to wait for one requestAnimationFrame before CSS classes were added/removed. The CSS classes are now applied directly after the first digest that is triggered after `$animate.addClass`, `$animate.removeClass` or `$animate.setClass` is called. If any of your code relies on waiting for one frame before checking for CSS classes on the element then please change this behavior. If a parent class-based animation, however, is run through a JavaScript animation which triggers an animation for `beforeAddClass` and/or `beforeRemoveClass` then the CSS classes will not be applied in time for the children (and the parent class-based animation will not be cancelled by any child animations). Closes angular#11975 Closes angular#12276

Narretz added the component: ngAnimate label May 29, 2015

Narretz added this to the Purgatory milestone May 29, 2015

Narretz assigned matsko Jun 9, 2015

matsko mentioned this issue Jun 30, 2015

Synchronous Classes in ngAnimate #12248

Closed

matsko mentioned this issue Jul 13, 2015

fix(ngAnimate): ensure that orphaned elements do not throw errors when animated #12338

Closed

matsko closed this as completed in e4aeae0 Jul 14, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Animations should not cancel parent animations #11975

Animations should not cancel parent animations #11975

jonrimmer commented May 29, 2015

Narretz commented May 29, 2015

matsko commented Jun 9, 2015

matsko commented Jun 30, 2015

matsko commented Jul 20, 2015

jonrimmer commented Jul 21, 2015

jonrimmer commented Jul 21, 2015

Narretz commented Jul 21, 2015

jonrimmer commented Jul 21, 2015

poshest commented Aug 13, 2015

poshest commented Aug 17, 2015

Animations should not cancel parent animations #11975

Animations should not cancel parent animations #11975

Comments

jonrimmer commented May 29, 2015

Narretz commented May 29, 2015

matsko commented Jun 9, 2015

matsko commented Jun 30, 2015

matsko commented Jul 20, 2015

jonrimmer commented Jul 21, 2015

jonrimmer commented Jul 21, 2015

Narretz commented Jul 21, 2015

jonrimmer commented Jul 21, 2015

poshest commented Aug 13, 2015

poshest commented Aug 17, 2015