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

input: ng-messages do not work if animation is disabled #10240

Closed
nikclayton opened this issue Jan 9, 2017 · 6 comments
Closed

input: ng-messages do not work if animation is disabled #10240

nikclayton opened this issue Jan 9, 2017 · 6 comments
Assignees
Labels
g3: reported The issue was reported by an internal or external product team. P2: required Issues that must be fixed. resolution: fixed severity: regression This issue is related to a regression
Milestone

Comments

@nikclayton
Copy link

Actual Behavior:

With a form like:

<form name="f">
  <md-input-container class="md-block">
    <label>Some text</label>
    <input type="text" name="i" placeholder="Enter something" required />
    <div ng-messages="f.i.$error">
      <div ng-message="required">This field is required.</div>
    </div>
  </md-input-container>
</form>

Everything works -- tab in to the field, tab out, and the field behaves as expected. Specifically:

  1. The placeholder text "Enter something" appears in red.
  2. The form field is underlined in red.
  3. The text "This field is required." appears underneath the field.

However, if your app turns off animation by, for example, injecting a $animate instance and calling $animate.enabled(false), (1) and (2) still occur, but (3) no longer happens -- the ng-message does not appear.

This is a regression from 1.0, where it did work.

CodePen (or steps to reproduce the issue): *

If you change that to $animate.enabled(true) the errors will start appearing again.

Angular Versions: *

  • Angular Version: 1.5.x
  • Angular Material Version: 1.1.x

Additional Information:

  • Browser Type: * Chrome.
  • Browser Version: * 55.0.2883.87
  • OS: * Ubuntu 14.04
  • Stack Traces: N/A
@jelbourn jelbourn added the g3: reported The issue was reported by an internal or external product team. label Jan 9, 2017
@clshortfuse clshortfuse self-assigned this Jan 10, 2017
@nikclayton
Copy link
Author

Suspect that cf7f21a is the culprit, which unconditionally uses $animate() to add new classes instead of checking to see if animation is enabled.

@clshortfuse
Copy link
Contributor

@nikclayton Correct. I'm the process of moving the animations to pure CSS. It just needs more testing but I'll probably have it ready for today.

The reason why we moved to $animate was due to a flicker bug. We can now move back to CSS because of the newer ng-enter-prepare class that was added since.

clshortfuse added a commit that referenced this issue Jan 10, 2017
With commit cf7f21a, animations were moved to input.js in response to an ng-enter
flicker issue with Angular 1.4.x. While the flicker was fixed, new animation bugs
arised. Angular 1.4.x added and backported a ng-enter-prepare to avoid this bug.

* Remove JS animations for input messages
* Use `.ng-enter-prepare` to avoid flicker on Angular 1.4+
* Use `.ng-enter:not(ng-enter-active)` to prepare animations on 1.3+ and below
* Update spec tests to use getComputedStyle instead of ngAnimate

Fixes #6767, #9543, #9723, #10240

Related: angular/angular.js#13408
clshortfuse added a commit that referenced this issue Jan 10, 2017
With commit cf7f21a, animations were moved to input.js in response to an ng-enter
flicker issue with Angular 1.4.x. While the flicker was fixed, new animation bugs
arised. Angular 1.4.x added and backported a ng-enter-prepare to avoid this bug.

* Remove JS animations for input messages
* Use `.ng-enter-prepare` to avoid flicker on Angular 1.4+
* Use `.ng-enter:not(.ng-enter-active)` to prepare animations on 1.3+ and below
* Update spec tests to use getComputedStyle instead of ngAnimate

Fixes #6767, #9543, #9723, #10240

Related: angular/angular.js#13408
clshortfuse added a commit that referenced this issue Jan 10, 2017
With commit cf7f21a, animations were moved to input.js in response to an ng-enter
flicker issue with Angular 1.4.x. While the flicker was fixed, new animation bugs
arised. Angular 1.4.x added and backported a ng-enter-prepare to avoid this bug.

* Remove JS animations for input messages
* Use `.ng-enter-prepare` to avoid flicker on Angular 1.4+
* Use `.ng-enter:not(.ng-enter-active)` to prepare animations on 1.3 and below
* Update spec tests to use getComputedStyle instead of ngAnimate

Fixes #6767, #9543, #9723, #10240

Related: angular/angular.js#13408
clshortfuse added a commit that referenced this issue Jan 10, 2017
With commit cf7f21a, animations were moved to input.js in response to an ng-enter
flicker issue with Angular 1.4.x. While the flicker was fixed, new animation bugs
arised. Angular 1.4.x added and backported a ng-enter-prepare to avoid this bug.

* Use `.ng-enter-prepare` to avoid flicker on Angular 1.4+
* Use `.ng-enter:not(.ng-enter-active)` to prepare animations on 1.3 and below

Fixes #6767, #9543, #9723, #10240

Related: angular/angular.js#13408
clshortfuse added a commit that referenced this issue Jan 10, 2017
With commit cf7f21a, animations were moved to input.js in response to an ng-enter
flicker issue with Angular 1.4.x. While the flicker was fixed, new animation bugs
arised. Angular 1.4.x added and backported a ng-enter-prepare to avoid this bug.

* Use `.ng-enter-prepare` to avoid flicker on Angular 1.4+
* Use `.ng-enter:not(.ng-enter-active)` to prepare animations on 1.3 and below
* Update spec tests to use computedStyle

Fixes #6767, #9543, #9723, #10240

Related: angular/angular.js#13408
@clshortfuse clshortfuse added the has: Pull Request A PR has been created to address this issue label Jan 10, 2017
@topherfangio topherfangio removed the has: Pull Request A PR has been created to address this issue label Mar 20, 2017
@topherfangio
Copy link
Contributor

I've removed the has: Pull Request label because the PR didn't account for many instances. I think we should just check if animation is enabled and if not, call element.addClass(). I will look into this soon.

@topherfangio topherfangio added needs: investigation The cause of this issue is not well understood and needs to be investigated by the team or community P2: required Issues that must be fixed. labels Mar 20, 2017
@Splaktar Splaktar added the severity: regression This issue is related to a regression label May 4, 2018
@Splaktar Splaktar added this to the 1.1.10 milestone May 4, 2018
@Splaktar Splaktar self-assigned this May 4, 2018
@Splaktar Splaktar modified the milestones: 1.1.10, 1.1.11 Jun 26, 2018
@Splaktar Splaktar modified the milestones: 1.1.11, 1.1.12 Sep 10, 2018
@Splaktar Splaktar modified the milestones: 1.1.12, 1.1.13 Jan 3, 2019
@Splaktar Splaktar modified the milestones: 1.1.13, 1.1.14 Feb 10, 2019
@Splaktar Splaktar changed the title ng-messages + ngmaterial 1.1 do not work if animation is disabled input: ng-messages do not work if animation is disabled Feb 12, 2019
@Splaktar Splaktar removed the needs: investigation The cause of this issue is not well understood and needs to be investigated by the team or community label Feb 12, 2019
@Splaktar
Copy link
Member

I updated the CodePen to 1.1.12 and it appears to be working properly. It looks like this was fixed indirectly already.

@clshortfuse
Copy link
Contributor

Looks like it was fixed in 0151b4b

The commit didn't closed the issue. I'm not entirely sure why.

@Splaktar
Copy link
Member

@clshortfuse thank you! It didn't close it because you need a Fixes for each issue #. I.e. Fixes #. Fixes #.

@Splaktar Splaktar modified the milestones: 1.1.12, 1.1.5 Feb 12, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
g3: reported The issue was reported by an internal or external product team. P2: required Issues that must be fixed. resolution: fixed severity: regression This issue is related to a regression
Projects
None yet
Development

No branches or pull requests

5 participants