Side navigation
#4035 closed bug (patchwelcome)
Opened January 31, 2009 08:27AM UTC
Closed March 31, 2011 05:47PM UTC
change event firing for disabled options in select
Reported by: | Topolopolopolov | Owned by: | brandon |
---|---|---|---|
Priority: | minor | Milestone: | 1.3.2 |
Component: | event | Version: | 1.3.1 |
Keywords: | change disabled option select | Cc: | miketaylr |
Blocked by: | Blocking: |
Description
The change event gets triggered for clicks on options within a select that have the 'disabled' attribute in some browsers. This only seems to happen when the size attribute of the select is greater than 1.
Safari and Chrome both fire the change event and return null for the val() of the select (even if a value attribute is supplied for the disabled option).
Opera fires the event and returns the value attribute of the previously selected option.
Firefox is handling it correctly, I would assume, and the change event doesn't fire on a click of the disabled option.
See attached file for example.
Attachments (1)
Change History (4)
Changed January 31, 2009 03:02PM UTC by comment:1
Changed October 29, 2010 03:08PM UTC by comment:2
status: | new → open |
---|
Issue no longer exists, except in:
Opera10.60 (fires last item selected)
Additionally:
IE6 & 7 do not support disabled attr
Changed October 29, 2010 03:26PM UTC by comment:3
cc: | → miketaylr |
---|
Changed March 31, 2011 05:47PM UTC by comment:4
resolution: | → patchwelcome |
---|---|
status: | open → closed |
I think browser behavior is too varied here to try and force a single cross-browser behavior. If someone has a solution they think might be able to fit into core, please contact us.
Here's the W3C discussion on select and option:
http://www.w3.org/TR/html401/interact/forms.html#h-17.6
It seems like some of this discussion does not apply:
http://www.w3.org/TR/html401/interact/forms.html#adef-disabled
The select is not disabled, so having the change event fire seems like it's still compliant. Safari and Chrome seem to be deselecting the current option when a disabled option is clicked, and they correctly realize that a disabled option cannot be selected. That results in the change event firing and the select's selectedIndex property being set to -1. So based on what the browser did it really did make sense to fire the change event.
I agree the Firefox behavior is the nicest; IE8 RC1 does it that way as well. Normalizing the other browsers to this behavior would require jQuery to know the selected options in advance of the click, detect selection of a disabled option, reset the options back to their previous values, and swallow the change event. Seems like way too much effort, but knowing the information above you can do it yourself.