Inconsistent behavior between .val() and .prop("value") for <select>

[kbondar]

When <select> (select-one) has <options> with duplicate values, setting the value .prop("value", "value") selects first option, while using .val("value") selects last option.

​http://jsfiddle.net/Jqnh6/

The problem lies in jQuery.valHooks.select.set

It might be worth to bail out of .each() as soon as option is selected and select type is select-one - also for performance reasons

[dmethvin]

Kind of a corner case but worth discussion. Seems like it could be fixed in the .each() with something like return !selectOne || !this.selected; to bail out early.

Which situation and/or browser(s) prevent us from just assigning to the .value property on a select-one element? Seems to work even in IE6. I see #2252 but that's not really related.

[Timmy Willison]

The val code for selects is shared between multiple and select-one types. This is great for us in terms of maintainability and size without a loss in performance. So, if we can keep from forking the code path, that would be awesome. As far as prop is concerned, it is a very bare method that should stay that way. I'd say use at your own risk and know that you are working with raw properties.

[kbondar]

dmethvin:

Seems to work even in IE6

Specified in HTML DOM Level 1, though I believe early Safari versions did not supported it - select.value was added for sure in Safari 4.

FF and Opera have it for ages.

[kbondar]

Replying to timmywil:

The val code for selects is shared

The problem arose when porting plain JS code to jQuery. If assignment to select.value selects first matching option I believe .val(value) should behave the same. Speaking of performance, getting the value from select.value or even using select.options[select.selectedIndex].value is all the way faster than looping through the list of options, is not it?

[dmethvin]

Duplicate of #11735.

[Timmy Willison]

I'll take this, but I'm not too worried about it for 1.8. The solution will probably add some bytes, and it can wait because although the behavior differs from native JS, it will change the way jQuery has always handled this.

[dmethvin]

Thinking about it some more, I am not convinced we should do anything. This is an edge case; if someone wants our "official" word on the value with the various valHooks shims they should be using .val() rather than .prop() or direct property access.

[Timmy Willison]

+1 @dmethvin