ngOptions treats a model viewValue of 0 as the unknown option, resulting in the proper value of the select not being selected

[hamfastgamgee]

If you define a select using a model with a value of 0, the "unknown option" will get added to the list and the proper selection in the will not be chosen. The problem is this line in self.removeOption: https://github.com/angular/angular.js/blob/master/src/ng/directive/select.js#L215 if (ngModelCtrl.$viewValue == value) { The double-equals check ends up evaluating 0 against the empty string, which succeeds and causes the "unknown option" to be rendered. This needs to be triple-equals, so that 0 really means 0. I strongly suspect that the same should be the case in self.addOption in a similar circumstance. However, I have not found a situation in which the addOption code was problematic (which doesn't mean that none exists). This bug exists minimally in 1.3.3 and 1.2.26.

[lgalfaso]

With only an initial look, it seems to be a bug

[Siyfion]

I've been having all kinds of issues with the select directive recently, what with #9639 and #9949, now this. I think it needs a proper test-suite written for it as it seems with each release it's getting more and more broken! 😒

[hamfastgamgee]

I wonder if the spot I found as broken was exposed by the fix for #9639 (i.e. broken as a different way prior to that fix). In any case, this fix is still needed on top of that.

[ghost]

I very much agree that the select needs an improved test suite. Most of my problems with Angular recently have been with the functionality of select changing from one release to another. This is the reason why I am currently running the June beta of Angular 1.3. Is "Improved test suite for Select" something that could be added to issues?

[hamfastgamgee]

Here's a plunker that reproduces the issue I'm seeing: http://plnkr.co/edit/qhf4gZeEIMlgPOtDao7k?p=preview

I'm currently working around the issue by detecting the "unknown option" that gets rendered, removing it, and remaking the selection, but obviously it's better fixed in the core code. :)

If the "data" array in the plunker is set up front without the $timeout call, everything works. It doesn't get into the "unknown option" cases, and the 0 option is selected. (In my real world case, my "data" is getting set by a $watch() on a property that's fed from an AJAX call. I'm not using $timeout, but it's the same general idea.)