This repository has been archived by the owner on Apr 12, 2024. It is now read-only.
Animations start, cancel and start again on slow mobile devices using iOS or old Android versions #6739
Assignees
Labels
Milestone
Comments
|
I'll play around with my iphone to see if this can be avoided somehow. Although the I should have an answer for this issue this week since there may be a change in the CSS code for 1.3. |
|
Do you think it would be possible, instead of reading the timing, use the |
|
We do use |
|
Currently working on a refactor that avoids the mess of toggling classes. It'll have a few script files for you to test later today. |
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 25, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 25, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 25, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 25, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 25, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 26, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 26, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 26, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
matsko
added a commit
to matsko/angular.js
that referenced
this issue
Mar 26, 2014
$animate attempts places a `transition: none 0s` block on the element when the first CSS class is applied if a transition animation is underway. This works fine for structural animations (enter, leave and move), however, for class-based animations, this poses a big problem. As of this patch, instead of $animate placing the block, it is now the responsibility of the user to place `transition: 0s none` into their class-based transition setup CSS class. This way the animation will avoid all snapping and any will allow $animate to play nicely with class-based transitions that are defined outside of ngAnimate. Closes angular#6674 Closes angular#6739 BREAKING CHANGE: Any class-based animation code that makes use of transitions and uses the setup CSS classes (such as class-add and class-remove) must now provide a empty transition value to ensure that its styling is applied right away. In other words if your animation code is expecting any styling to be applied that is defined in the setup class then it will not be applied "instantly" default unless a `transition:0s none` value is present in the styling for that CSS class. This situation is only the case if a transition is already present on the base CSS class once the animation kicks off.
|
No more class-toggling. The patch landed as 1bebe36 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In the current implementation, when you call addClass/removeClass, to get the timing, the library adds the class, gets the timing and removes the class again, hoping that the browser wouldn't notice if it's fast enough. And then it adds the class again to make the actual animation.
The problem with this, is that with slower devices, the browser starts the animation before the code has time to remove the class. This causes the animation to start, cancel, and then start again.
You can check the bug on mobile devices using the following fiddle (full screen version). I added some layers to make the device choke a little. I tested that fiddle causing the issue, on a current gen iPod Touch, running iOS 7. Also tested on an iPod Touch 4g running iOS 6.1. And it also happened using the vanilla Android Browser on Android 4.1 in the Android emulator. You might have to tap a few time before you see the issue.
On mobile or desktop Chrome the issue is not visible, at least on Android 4.4.2.
The text was updated successfully, but these errors were encountered: