#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: |
Description
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 10 years ago by
Owner: | set to neyer |
---|---|
Status: | new → pending |
comment:2 Changed 10 years ago by
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 follow-up: 4 Changed 10 years ago by
Component: | unfiled → attributes |
---|---|
Milestone: | None → 1.9 |
Priority: | undecided → high |
Status: | pending → open |
Oh now I remember this.
https://github.com/jquery/jquery/commit/425d17de832d281c2577f8d6653030cef95907b5
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 Changed 10 years ago by
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-one
s?
comment:5 Changed 10 years ago by
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 10 years ago by
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-one
s 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 10 years ago by
Resolution: | → wontfix |
---|---|
Status: | open → closed |
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 10 years ago by
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)
1.2
1.3
1.4
1.6.3
1.7.1
1.8.0
1.8.2
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 10 years ago by
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.
This looks to me like a fix. Can you provide reason why we should ignore the
disabled
attribute in this case?