Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why inputs are touched onload? #167

Open
carscx opened this issue Jun 29, 2016 · 5 comments
Open

Why inputs are touched onload? #167

carscx opened this issue Jun 29, 2016 · 5 comments
Labels

Comments

@carscx
Copy link

carscx commented Jun 29, 2016

The inputs onload initial are touched set true.

Steps to reproduce

  • Open page
  • view the $touched atributte input

What exactly is supposed to happen

I've create a JSFiddle with angular only http://jsfiddle.net/carscx/mjud3r47/1/ and I've modified their JSFiddle http://jsfiddle.net/nb8116u4/2/ to see the differences

A link to a page clearly demonstrating the issue

http://jsfiddle.net/nb8116u4/2/

@webbiesdk webbiesdk added the bug label Jul 8, 2016
@webbiesdk
Copy link
Collaborator

Yep, looks like a bug.

I think it is some of the initialization done by Materialize that is causing it, which is difficult to change.

I'll look more at it later.

@carscx
Copy link
Author

carscx commented Jul 10, 2016

Other example, if you to init the field, touched is false.

But is false always. If you erase all text touched be true.

http://jsfiddle.net/carscx/nb8116u4/3/

@kildareflare
Copy link

kildareflare commented Jul 28, 2016

We are seeing the same issue. We are using ngMessages for our clientside validation messages.
This bug means that all input fields have the ng-touched classed set before they have actually been used, and results in the input fields marked as in error.

Looking through the code is appears to be related to this line::

element.trigger("blur");

in the below code:

  angular.module("ui.materialize.ngModel", [])
        .directive("ngModel",["$timeout", function($timeout){
            return {
                restrict: 'A',
                priority: -1, // lower priority than built-in ng-model so it runs first
                link: function(scope, element, attr) {
                    scope.$watch(attr.ngModel,function(value, oldValue){
                        $timeout(function () {
                            // To stop an infinite feedback-loop with material multiple-select.
                            if (value instanceof Array && oldValue instanceof Array) {
                                if (value.length == oldValue.length) {
                                    return;
                                }
                            }
                            if (value){
                                element.trigger("change");
                            } else if(element.attr('placeholder') === undefined) {
                                if(!element.is(":focus"))
                                    element.trigger("blur"); //this line causes the issue
                            }
                        });
                    });
                }
            };
        }]);

If I remove that line all is good. Any ideas why that line is needed?

@webbiesdk
Copy link
Collaborator

The element.trigger("blur"); is there to ensure that the "blur" events are triggered correctly, when the inputs are updated externally by ng-model.
So that line stays, in some form.

The fix might be to restrict when element.trigger("blur") is executed.

@mdobrzanski
Copy link

Ah, this got me today. I may be wrong, but it's blur suppose to happen when user clicks on different element? As an opposite to focus. It messes up how validation works in angularjs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants