You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
fix(ngAnimate): allow removal of class that is scheduled to be added with requestAnimationFrame
Also affects the reverse case, adding a class that is scheduled to be removed with rAF.
The following case can happen when ngClass updates an element's classes in very quick order in the following way:
- First animation adds class "a"
- A digest passes, but "a" is not yet added to the element
- Second animation adds class "b"
- No digest passes, and "a" is still not added to the element,
because requestAnimationFrame hasn't been flushed yet
- Third animation removes class "a"
- the third animation gets merged into the second animation
Before this change:
- Because the element doesn't have class "a" yet, ngAnimate
resolves that it cannot remove class "a". However,
the first animation is still running, and finally adds "a"
After this change:
- ngAnimate reacts to the temporary class "add-a", which indicates
that "a" is about to be added and decides that "a" can be removed
after all.
This is a very rare case where setting the element's class
is not fast enough, and subsequent animations operate on incorrect assumptions.
"In the wild", this is caused by rapidly updating ngClass,
which uses inidvidual addClass and removeClass calls when both operations happen in a single digest.
Fixes#14582
PR (#14760)
0 commit comments