When using select with ngOptions' disable keyword, and the model value is one that is disabled through the ngOptions directive, the select element doesn't show the model value.
The UI should show the value, but upon opening the select dropdown, the value should appear disabled.
What actually happens is, that the select shows as if there was no value in the model.
A model value can come from a record in a database, e.g. an option that was valid but no longer. In this case, the select doubles as display and input element. Due to this, it doesn't display a disabled value.
1.4.5 (as disable is new to 1.4)
Tested on OS X 10.10 Chrome, FF, Safari
http://plnkr.co/edit/unjDAvAUnBimn29URkSP?p=preview
Possibly #11762
I am not yet decided on whether this is a bug or a feature. (It's quite an "edge-y" case anyway.)
But here is a possible work-around:
<select
ng-model="value"
ng-options="val disable when ((val !== value) && (_some_condition_)) for val in values">
</select>
I think this could be a feature. You are not indicating a value to use when a disabled value is set. Probably an optional value/argument/filter or something could be added.
In real life, there are a lot of scenarios were it happens that a current value can't be picked anew. Think of a pricing plan picker, were you still might have the champions plan from the early beta as your current value, but the user editing their pricing plan can't pick that one any longer.
In my mind, the current value of the input element and the option picking are quite distinct responsibilities of this HTML element, and I believe there are good reasons to not conflate them when writing directive to support them in Angular.
I get your point and I also think this is a real use case. The problem that I see is that angular does not know what to do when you set the value to a disabled option. What do you propose to do?
Probably (I'm not sure) the ng-model value could change when a disabled option is selected. If that happens you could have to indicate what value to use. This is just an idea.
I remember that Firefox had a bit of a problem with disabled values being selected, but I can definitely see how it makes sense to show the selected value if it comes from the model.
It makes sense, but I think that when an option is disabled shouldn't be available to be selected. Maybe in this case the problem is to set the model with an "invalid" value. Anyway, I guess that the select should not select the disabled option or add a blank option.
If I'm wrong please let me know.
@gkalpak Your proposal is excellent and makes sense in 99% of data entry cases.
A inactive value can't be selected as new value for the field, but if the field already contains this value then your are allowed to keep it. More advanced or complex scenarios must be handled at record level anyway.
So I think that what you propose is much more than a work around, it is really the way we should use it and there is nothing to change.
Hi guys, having the same issue here. The use case is we want to deprecate some values that a user may selected them in the past. If he doesn't touch the select box we want to display the value that he selected it and now is disabled. If he change the value he can not select anymore.
The workaround proposed by @gkalpak is working well but still this feels a bit hacky.
So i will suggest to follow the browser implementation where you can have a selected value that is disabled.
I think since a normal select, as well as a select with ngModel but without ngOptions selects disabled options, we should do the same for ngOptions.
We are inclined to change ngOptions so that when a model is set to a value that matches a disabled option, the option will be selected and set as the select.value. This is in principle more of a visual change, as the only difference is that the select will now show that the disabled option is selected. Even before this change, the scope model value is set even if the associated option is disabled, so selecting the disabled option is consistent with the actual data model.
I was also checking in to see if @sjbarker as the creator of this feature has some opinion on this. :)
Sorry I'm late on this @Narretz. LGTM, though. I see no reason a disabled option shouldn't be rendered when selected programmatically, and no reason appears in the spec. Glad to see it made it in.
Yes, nice to see this change go in. Thanks to everyone involved.
Most helpful comment
I am not yet decided on whether this is a bug or a feature. (It's quite an "edge-y" case anyway.)
But here is a possible work-around: