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

Bug: ngAnimation classes skipped on enter when using ng-if on form that contains required email input #14249

Closed
poacher2k opened this issue Mar 16, 2016 · 3 comments

Comments

@poacher2k
Copy link

Hey!

What is the current behavior?
When you have a form that is shown using ngIf and contain an <input type="email" ng-model="someModel" required>, ngAnimate classes are not added when the ngIf statement becomes truthy.

Steps to reproduce
Link to demo

  1. Create a form that is shown with ngIf and contains an <input type="email" ng-model="someModel" required>
  2. Make ngIf statement truthy

What is the expected behavior?
ngAnimate classes should be added when ngIf statement becomes truthy.

What is the motivation / use case for changing the behavior?
Consistent behavior

Affected:
This occured when I tested with Chrome and Firefox on Linux, Safari on OSX, and Chrome / IE on Win7, both angular 1.5.x stable and snapshot.

Other information
It works as expected if:

  1. type="email" is changed to something else
  2. required is removed
  3. ngShow / ngHide is used instead of ngIf
@Narretz
Copy link
Contributor

Narretz commented Mar 16, 2016

Looks like it was caused by 776972e

Narretz added a commit to Narretz/angular.js that referenced this issue Mar 17, 2016
…anges

When multiple animations on the same element are queued before a $digest passes,
the animator tries to create as few actual animations as possible by joining / canceling
redundant animations. Class-based animations for example are cancelled when the classes that
are added and removed are the same, and the result is no class-change. This however must only
happen if there's no structural animation currently queued.

Fixes angular#14249
Narretz added a commit to Narretz/angular.js that referenced this issue Mar 17, 2016
…anges

When multiple animations on the same element are queued before a $digest passes,
the animator tries to create as few actual animations as possible by joining / canceling
redundant animations. Class-based animations for example are cancelled when the classes that
are added and removed are the same, and the result is no class-change. This however must only
happen if there's no structural animation currently queued.

Fixes angular#14249
@michi88
Copy link

michi88 commented Mar 20, 2016

This could very well also be related to lazy compilation with the ng-if transclude as discussed here: #14074

just my two cents

@Narretz
Copy link
Contributor

Narretz commented Mar 21, 2016

I don't think so, because you need very specific prerequisites. I've explained the cause in the linked OR

Narretz added a commit to Narretz/angular.js that referenced this issue Mar 21, 2016
Since email and url don't use $parsers, we do not need to set the parserName.
This also reduces the number of times the valid / invalid classes are
set within  for the input or possible parent forms.

This was discovered when fixing angular#14249. The additional class settings triggered
a cancellation of the structural animation. A general fix for this behavior has
landed as <insert commit here>
Narretz added a commit to Narretz/angular.js that referenced this issue Mar 23, 2016
…anges

When multiple animations on the same element are queued before a $digest passes,
the animator tries to create as few actual animations as possible by joining / canceling
redundant animations. Class-based animations for example are cancelled when the classes that
are added and removed are the same, and the result is no class-change. This however must only
happen if there's no structural animation currently queued.

Fixes angular#14249
Narretz added a commit that referenced this issue Mar 23, 2016
…anges

When multiple animations on the same element are queued before a $digest passes,
the animator tries to create as few actual animations as possible by joining / canceling
redundant animations. Class-based animations for example are cancelled when the classes that
are added and removed are the same, and the result is no class-change. This however must only
happen if there's no structural animation currently queued.

Fixes #14249
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.