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 … #14760
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…with requestAnimationFrame 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 angular#14582
|
LGTM |
Narretz
added a commit
that referenced
this pull request
Jun 23, 2016
…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)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
bug fix
What is the current behavior? (You can also link to an open issue here)
See #14582
Please check if the PR fulfills these requirements
Other information:
…with requestAnimationFrame
The following case can happen when ngClass updates an element's classes in very quick order in the following way:
because requestAnimationFrame hasn't been flushed yet
Before this change:
resolves that it cannot remove class "a". However,
the first animation is still running, and finally adds "a"
After this change:
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