Bug Tracker

#11535 closed bug (wontfix)

Opened March 30, 2012 01:58PM UTC

Closed October 22, 2012 05:45PM UTC

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

Attachments (0)
Change History (11)

Changed March 30, 2012 03:13PM UTC by dmethvin comment:1

milestone: None → 1.8
status: new → open

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.

Changed March 30, 2012 03:13PM UTC by dmethvin comment:2

component: unfiled → attributes
priority: undecided → low

Changed March 30, 2012 03:33PM UTC by timmywil comment:3

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.

Changed March 31, 2012 06:35AM UTC by kbondar comment:4

[comment:1 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.

Changed March 31, 2012 06:45AM UTC by kbondar comment:5

Replying to [comment:3 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?

Changed May 18, 2012 02:03AM UTC by dmethvin comment:6

resolution: → duplicate
status: open → closed

Changed May 18, 2012 02:03AM UTC by dmethvin comment:7

Duplicate of #11735.

Changed May 18, 2012 02:03AM UTC by dmethvin comment:8

resolution: duplicate
status: closed → reopened

Changed June 04, 2012 05:54PM UTC by timmywil comment:9

_comment0: 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 jQuery has always handled this. → 1338832473337576
milestone: 1.8 → 1.next
owner: → timmywil
status: reopened → assigned

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.

Changed July 11, 2012 04:49PM UTC by dmethvin comment:10

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.

Changed October 22, 2012 05:45PM UTC by timmywil comment:11

resolution: → wontfix
status: assigned → closed

+1 @dmethvin