Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

ngAnimate issue on ng-show with a nested ng-repeat #12276

Closed
Okazari opened this issue Jul 6, 2015 · 6 comments
Closed

ngAnimate issue on ng-show with a nested ng-repeat #12276

Okazari opened this issue Jul 6, 2015 · 6 comments
Assignees
@matsko
Labels
component: ngAnimate needs: work severity: regression
Milestone
1.4.4

Comments

@Okazari
Copy link

Okazari commented Jul 6, 2015

Hi, i was actually helping on stackoverflow for some issues and i ran into this one :
http://stackoverflow.com/questions/31245780/parent-child-animation-unexpected-different-angular-1-3-to-1-4/

After some try i was able to figure out where was the trouble :

On "ng-show/hide" with a nested "ng-repeat" there is no class "ng-hide-animate" added on the element during the animation.

This doesn't work on 1.4.0 - 1.4.1 - 1.4.2: http://codepen.io/anon/pen/EjEora
This works on 1.3.5 : http://codepen.io/anon/pen/VLXygP

Not having this class cause this to be applied during the animation.

.ng-hide:not(.ng-hide-animate) {
display: none !important;
}

Which result into not hiding the element before the animation end.

I'm also a bit confused about the documentation :

1.4.X documentation

CSS Class-based Animations
Class-based animations (animations that are triggered via ngClass, ngShow, ngHide and some other > directives) have a slightly different naming convention. Class-based animations are basic enough that a standard transition or keyframe can be referenced on the class being added and removed.

For example if we wanted to do a CSS animation for ngHide then we place an animation on the .ng-> hide CSS class:

The 1.4.X documentation specify that we shoudn't have this "ng-hide-animate". So i guess that the ng-hide:not(.ng-hide-animate) in the CSS shoudn't exist.

What do you think about this ? Is that a bug or just a miss-use ?
@havenchyk
Copy link

@Okazari works much better with 1.4.1 instead of 1.4.0, could you have a try?

@Okazari
Copy link
Author

Okazari commented Jul 7, 2015

@havenchyk Just tried with 1.4.1 and 1.4.2. still got the issue.

@planetflash
Copy link

@Okazari , @havenchyk , likewise, I have the same issue and no change on 1.4.0 - 1.4.2

@matsko
Copy link
Contributor

matsko commented Jul 14, 2015

The issue is because of the repeater cancelling out the parent classes. There is a fix that takes care of this issue: #12248

I just need a few days to do some more testing.

@matsko matsko self-assigned this Jul 14, 2015
@matsko matsko added this to the 1.4.4 milestone Jul 14, 2015
@matsko matsko mentioned this issue Jul 17, 2015
Closed
matsko added a commit to matsko/angular.js that referenced this issue Jul 17, 2015
@matsko
fix(ngAnimate): ensure that parent class-based animations are never c…
46f22ab 
…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
@matsko
Copy link
Contributor

matsko commented Jul 17, 2015

I confirm that #12248 fixes the issue.

@Okazari
Copy link
Author

Okazari commented Jul 17, 2015

@matsko Thank you, great work.

matsko added a commit to matsko/angular.js that referenced this issue Jul 17, 2015
@matsko
fix(ngAnimate): ensure that parent class-based animations are never c…
b16d747 
…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
matsko added a commit to matsko/angular.js that referenced this issue Jul 20, 2015
@matsko
fix(ngAnimate): ensure that parent class-based animations are never c…
9568d5b 
…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
matsko added a commit to matsko/angular.js that referenced this issue Jul 20, 2015
@matsko
fix(ngAnimate): ensure that parent class-based animations are never c…
04ca859 
…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
@matsko matsko closed this as completed in 32d3cbb Jul 20, 2015
netman92 pushed a commit to netman92/angular.js that referenced this issue Aug 8, 2015
@matsko @netman92
fix(ngAnimate): ensure that parent class-based animations are never c…
84f21e3 
…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
ggershoni pushed a commit to ggershoni/angular.js that referenced this issue Sep 29, 2015
@matsko
fix(ngAnimate): ensure that parent class-based animations are never c…
10627fb 
…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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@matsko matsko

Labels
component: ngAnimate needs: work severity: regression
Projects
None yet
Milestone
1.4.4
Development

No branches or pull requests
4 participants
@matsko @havenchyk @Okazari @planetflash