Bug when using ngModel, $asyncValidators and SELECT elements.

[duncangrist]

Tested and reproduced with version: 1.3.0-rc.0

If you use the relatively new $asyncValidators feature with SELECT elements bound to an ngModel the SELECT options become unselectable.

Please see the following plunk:
http://plnkr.co/edit/wlBKH2

This seems to be because $asyncValidators set the $modelValue to undefined while the async validators are running, but never set it back again to the actual value once all the async validators pass.

[gonzaloruizdevilla]

either PR #8861 or PR #8892 will solve this

[shahata]

No, I don't think so. This is is something else. This happens because select invokes render() right after $setViewValue() which sets an empty item as selected (since $modelValue is undefined). It can be easily solved by invoking ctrl.$render() when the async validator resolves, but I'm not sure if this is the best way to solve it.

@petebacondarwin WDYT? (this is somewhat remotely related to cdc7db3f)

[petebacondarwin]

@shahata - without looking deeply into this, calling render() when the validator resolves (i.e. we are no longer pending) may work but perhaps we could go the other way and not call render() directly after $setViewValue() if we are in a $pending state?

[gonzaloruizdevilla]

I'm not sure this is the way to go, and it is not resolving the issue in all the cases. When you change a value in the select, the async validators are triggered three times instead of only once.

UPDATE: in the plnkr, the changes in the select triggers its own async validation, then it triggers input async validation and then the select async validation is triggered a second time. Actually, I find it very difficult to determine what the expected behavior should be when both the input and the select have async validations on the same model value.

http://plnkr.co/edit/EDuXlZopgARZ93kYSvGy?p=preview
(this plnkr is a fork of @shahata 's )

[shahata]

@petebacondarwin hmm, but if render() isn't called then I guess there would be some bad consequences. After all, it's invoked there for a reason... From what I see, the reason render() is invoked there is in order to add/remove the "?" option when it becomes selected/unselected.

Truth is I'm a bit confused by this render() function. Why does it have to use $modelValue and not $viewValue? I think just changing everything to $viewValue will solve this issue and will not break anything, but there is a good chance I'm missing something... I'm sending a PR to test this.

[duncangrist]

Glad this seems to be getting traction - when/if you do get a satisfactory fix, be sure to double check that selecting 0 (zero) works as when I quickly hacked my angular copy to fix this issue, I found that another bug stopped the selection of zero.
I narrowed that bug down to NgModelController.$$setPending, resolve function - where it calls var value = ctrl.$viewValue || ''; and then uses that subsequent value when calling ctrl.$$updateValidModelValue(value);. This behaviour is causing 0 to be converted to an empty string which is then stored against the model.

Let me know if there's anything else I can do.

[shahata]

@maximumduncan you can play around with this to see if your issue is resolved: http://plnkr.co/edit/3CDLMe?p=preview
regarding the "0 becomes empty string thing", you'd better open a different issue for that, but the easy workaround is to use a string array instead of number array: ['0','1','2',...]

[duncangrist]

@shahata - yes, that does seem to resolve the original bug thanks.

However, I disagree on the viability of your workaround for the "0 becomes empty string thing" because normally angular has no trouble when using zeros in selects. In your Plunk, if you remove the async-validate attribute from the select, and convert the strings back to ints, you'll see that zero behaves just like all the other numbers. It appears that it's specifically being broken by the $asyncValidators feature.

[shahata]

Yes, I agree that this should be reported as a different issue. The workaround is just that - a way to work around the issue.

[duncangrist]

Fair enough - I was going to raise it as an issue, but I hesitated because it's not actually a reproducible issue until this Issue's bug is resolved. What would you suggest is the correct play here?