Bug Tracker

Opened 8 years ago

Closed 7 years ago

#11535 closed bug (wontfix)

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

Reported by: kbondar Owned by: timmywil
Priority: low Milestone: 1.next
Component: attributes Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:

Description

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

Change History (11)

comment:1 Changed 8 years ago by dmethvin

Milestone: None1.8
Status: newopen

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.

comment:2 Changed 8 years ago by dmethvin

Component: unfiledattributes
Priority: undecidedlow

comment:3 Changed 8 years ago by timmywil

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.

comment:4 in reply to:  1 Changed 8 years ago by 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.

comment:5 in reply to:  3 Changed 8 years ago by 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?

comment:6 Changed 8 years ago by dmethvin

Resolution: duplicate
Status: openclosed

comment:7 Changed 8 years ago by dmethvin

Duplicate of #11735.

comment:8 Changed 8 years ago by dmethvin

Resolution: duplicate
Status: closedreopened

comment:9 Changed 8 years ago by timmywil

Milestone: 1.81.next
Owner: set to timmywil
Status: reopenedassigned

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.

Last edited 8 years ago by timmywil (previous) (diff)

comment:10 Changed 7 years ago by 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.

comment:11 Changed 7 years ago by timmywil

Resolution: wontfix
Status: assignedclosed

+1 @dmethvin

Note: See TracTickets for help on using tickets.