Bug Tracker

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#13097 closed bug (wontfix)

using .val() on a disabled html-select-option has different results since 1.8.3

Reported by: neyer Owned by: neyer
Priority: high Milestone: 1.9
Component: attributes Version: git
Keywords: Cc:
Blocked by: Blocking:


Switch the version of jQuery to 1.8.3 (in the html-part) or to jquery-git. In versions before 1.8.3 you get the result 'somevalue', while since 1.8.3 'null' is returned: http://jsfiddle.net/J6ADy/ (Tested and reproducable in Chrome 23, FF 17, IE7, IE8, IE9)

Change History (9)

comment:1 Changed 5 years ago by gibson042

Owner: set to neyer
Status: newpending

This looks to me like a fix. Can you provide reason why we should ignore the disabled attribute in this case?

comment:2 Changed 5 years ago by dmethvin

If were were serializing the value using form rules I agree we should ignore it, but in this case we're just getting the current value and it seems like this should work.

comment:3 Changed 5 years ago by dmethvin

Component: unfiledattributes
Milestone: None1.9
Priority: undecidedhigh
Status: pendingopen

Oh now I remember this.


But the ticket ref there is wrong, it's #12584. The reporter wanted .serialize() to not submit the value, and it rightly should not. But the fix needs to be there so it's still possible to get the value.

comment:4 in reply to:  3 Changed 5 years ago by gibson042

Replying to dmethvin:

But the fix needs to be there so it's still possible to get the value.

For all selects, or only select-ones?

comment:5 Changed 5 years ago by dmethvin

I think it should return values from .val() in all cases, but of course for the multi-selects it has to return an array.

comment:6 Changed 5 years ago by gibson042

No, what I'm getting at is that we have long-standing logic in .val() to exclude disabled options from the return value. It's most useful for select-multiple but applies universally, and the fact that it was overridden for select-ones appears to be an unintentional side effect of fixing #2551.

At any rate, introducing a difference in the treatment of disabled options is likely to generate future bug reports whether or not it includes select-multiple. I'm personally inclined to have .val() stick with form serialization rules and tell anyone wanting more detailed information to use selectedIndex directly.

comment:7 Changed 5 years ago by dmethvin

Resolution: wontfix
Status: openclosed

I agree with you on this @gibson042 so I'll close this wontfix. It's up to the page developer to either keep the controls in a reasonable state or deal with the inconsistencies and conflicts. Having an option both selected and disabled isn't very useful.

comment:8 Changed 5 years ago by neyer

An option can be disabled and selected (usually 'selected' through JS code). It's quite usefull in my opinion and used a lot like in following example:


Also kind of related post/discussion about selected-and-disabled options: http://stackoverflow.com/questions/49790/in-html-what-should-happen-to-a-selected-disabled-option-element

So according to html docs, "Disabled controls cannot be successful." http://www.w3.org/TR/html401/interact/forms.html#disabled
'successful' means "A successful control is "valid" for submission" http://www.w3.org/TR/html401/interact/forms.html#successful-controls

So from my point of view .val() should still return the value of a disabled-and-selected option.

According to @gibson042 'we have long-standing logic in .val() to exclude disabled options from the return value':
I tested the jsfiddle-codesnippet with following jQuery versions:
1.1.2 (could not find older one)

and all versions worked like I expected it, i.e. the value of the disabled-and-selected option is returned.

Only newest versions (1.8.3 and 1.9xxx) return 'null' instead of the value. So the logic was constistent since february 2007 (or longer?) and has changed in the last few weeks...

comment:9 Changed 5 years ago by dmethvin

The long-standing logic in .val() ensures that we don't return disabled options in a select-multiple. The change just applies the same behavior for select-one now for consistency. You can get to the disabled option value through $("select").prop("selectedIndex") if you need it.

Note: See TracTickets for help on using tickets.