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

Input[type=email] is not reset on model reset #10027

Open
martinczerwi opened this issue Nov 12, 2014 · 7 comments
Open

Input[type=email] is not reset on model reset #10027

martinczerwi opened this issue Nov 12, 2014 · 7 comments

Comments

@martinczerwi
Copy link

There's a bug with updating view values when an input of type email contains invalid content and its model is an objects' property.

A practical example is resetting an object using angular.copy with an empty object, like it's done in most examples in the Developer Guide, Chapter "Forms" (https://docs.angularjs.org/guide/forms).

I've created a plunk with simple instructions, which demonstrate the bug: http://plnkr.co/edit/cJgs2Nji79hxF1m5doRM?p=preview

The reason this happens, is that email inputs don't get their model values updated, if the content is invalid. Later when a model change happens, NgModelController determines the value via ngModelGet($scope); and compares this to ctrl.$modelValue (see this line:

if (modelValue !== ctrl.$modelValue) {
).

Both are undefined, in case you didn't enter any valid input before, and therefore the view value is not updated.

If noticed ctrl.$dirty is set to true, on the line above, so a simple fix could be to also ask if $dirty is true. But I can't estimate the performance hit, and can't help with tests as I'm still pretty new to angular internals.

Please help and verify, or tell me if I got something wrong.

@caitp
Copy link
Contributor

caitp commented Nov 12, 2014

i'm not really sure what you're talking about, it looks like it's behaving as expected to me. Can you explain what you're expecting from the plunker? In terms of observable behaviour, I mean.

@Siecje
Copy link

Siecje commented Nov 12, 2014

I believe the bug report is for the fact that the email field still has a value after you click RESET but the name field does not.

I assume it is because user.email never changed to trigger the update in the input.

I don't agree with "though form model is reset." since the email was never set (it was always '', since the email field was never valid).

Since $scope.master doesn't exist yet. (You have not clicked SAVE) you are doing

$scope.user = angular.copy(undefined);

@martinczerwi
Copy link
Author

Plunk is now updated, sorry guys, I got things a bit messed up. $scope.reset should have been named $scope.master and should be an empty object.

@Siecje You basicly got it right, the email field still has a value after resetting. What you didn't agree with was because of my fault, the reset call should do this

$scope.user = angular.copy($scope.master);
// Which effectively does this
// $scope.user = angular.copy({});

Then $scope.user would be an empty object, and therefore name and email should be empty. View values however don't update correctly, email field keeps its content.

Defining $scope.master with attributes name and email (both either empty string or null) makes this work as expected:

$scope.master = {
  name:'',
  email:''
}

@Narretz
Copy link
Contributor

Narretz commented Nov 13, 2014

I believe it would be better to reset the values from view -> model, that means through the form. We could add a $reset function or similar. The behavior of the reset function in the plunker is expected. Too bad it's in the docs like that .. hmpf!

@petebacondarwin
Copy link
Member

This is an interesting problem which is related to the discussion at #5449. I personally feel that this is a good use case for always passing the view value through the parsers to the model whether or not it is valid. The validation flags will indicate that the email value is invalid but will make it easy to clear without the need to add extra $reset type methods. Also this approach gives the flexibility to add on additional parsing strategies (such as set to undefined or leave alone) when the value is invalid.

@Narretz
Copy link
Contributor

Narretz commented Dec 11, 2014

Yeah, that's one possible way to do it. But you couldn't use the parsers to set it to undefined if invalid, because validation happens afterwards. We'd need some sort of update that is customizable and is called after validation, but before the model update (basically it would decide if the model is updated or not, and with what)

@petebacondarwin
Copy link
Member

We need to fix this but I am wondering if it needs to be part of a bigger refactoring inside ngModel that should occur in 1.5. Fancy taking this on @Narretz ?

@Narretz Narretz modified the milestones: 1.4.x, 1.5.x - migration-facilitation Sep 19, 2015
@Narretz Narretz modified the milestones: 1.5.x, Backlog Apr 21, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants