A minimal testcase uploaded using "Add an attachment" would be great.
Component: Untriaged → DOM
Product: Firefox → Core
> The onchange event should fire when the selected option is altered The spec and accesibility considerations disagree with you. A keyboard-only user should be able to select a new value without onchange firing on all intermediate values. > Is there a reason why Firefox has made a different decision on this issue than every > other browser? Because we're apparently the only ones who care whether keyboard-only users can use the web. In any case, here's the relevant spec bit: If the multiple attribute is absent, and the element is not disabled, then the user agent should allow the user to pick an option element in its list of options that is itself not disabled. Upon this option element being picked (either through a click, or through unfocusing the element after changing its value, or through a menu command, or through any other mechanism), and before the relevant user interaction event is queued (e.g. before the click event), the user agent must set the selectedness of the picked option element to true, set its dirtiness to true, and then send select update notifications. note the "unfocusing the element" bit. This is also how other form controls work. If you type in an input, you don't get an onchange until you blur it. Of course all this has been discussed at length before....
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 126379
Boris - Similar to some other posts I've been reading on the subject, I would tend to disagree with w3c specs on this one. If both onchange and onblur fire on blur, then what is the point of having both? How, with these specs, can someone develop ajax lookups? For example, if you write a date lookup where you select the month from one drop down list and then the list of days adjusts its contents based on the month selection. If the person is a keyboard-only user, when they press tab to navigate to the Day dropdown box, the onchange would only then fire, making the ajax fire and changing the focus (since for a split second the Day element is vacant while it is being calculated). For other browsers, you can set your ajax to fire onchange and then the Day select dropdown will be all ready to go by the time the user presses tab. As far as accessibility goes, w3c hasn't seemed to consider dynamically filled selections, because this standard actually makes such sites LESS accessible. I know, it's the programmer's fault for not bothering to work around these standards, but in reality, this is how many websites are built; in large part because most other browsers behave that way, so adhering strictly to the w3c standards on this issue seems a bit idealistic and detrimental. Anyways, I know you won't change your mind on my account, but I saw this as a bug which actually hinders accessibility rather than helps it.
> what is the point of having both? Onchange fires in cases other than onblur. Onchange doesn't fire if the value hasn't changed. Why are the issues you raise not issues for <input type="text">?
Largely because text inputs have onkeydown or onkeyup. These can be used to fire ajax calls while the user is typing, as the text is "changing". To do the same with a selection dropdown, you would have to read the input event keycode to determine whether or not it is a key that would change the active option. It's possible but not very ideal. Developers are bound to miss a keystroke or two that they didn't think of - especially when considering international accessibility.
Hmm. Seems like the right thing to do would be to fire "input" events when what the user has selected changes (just like we fire "input" events when the text in a text control changes) and fire "change" when the change is committed...
You need to log in before you can comment on or make changes to this bug.