User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050508 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050508 Firefox/1.0+ Assume a form is on display that contains a <select> element containing multiple <option> elements. Once the field has focus, keyboard events (e.g. typing a letter, using the arrow keys) will change the value of the element. However, the onchange event is not fired. (Changing the selected sub-element using the mouse does however fire the event as expected.) Reproducible: Always Steps to Reproduce: 1. View a form containing a <select> element with an "onchange" action, e.g. <select name="example" onchange="alert('Select value changed');"> ... </select> 2. Set the focus to the <select> element. 3. Use the arrow keys to change the selected option. Actual Results: The "onchange" action did not occur. Expected Results: The "onchange" action should occur.
Can you knock a testcase together and attach it to this bug report using https://bugzilla.mozilla.org/attachment.cgi?bugid=296125&action=enter ?
Related to / dupe of bug 126379?
Replying to #2: yes, I think this is the same bug. (I'm surprised that I didn't find it when I very carefully searched on "select", "onchange" and "keyboard". Perhaps "down arrow" would have been better!) I was astonished to see bug 126379 described as "wontfix" when it is so obviously a bug and causes serious compatibility problems for Firefox users accessing our site. I suppose I had better plead for reassessment under 126379.
The logic is that you are just making a choice using the arrow keys, like the mouse hover. The change event happens once the select box no longer has focus or pressing the enter key. *** This bug has been marked as a duplicate of 126379 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
Re #5: That is certainly as good a rationalization as one could expect for an unsatisfactory state of affairs. I don't know about "logic" though. I do not see why the "logic" changes as soon as the select element has a size attribute greater than 1. Nor can I see why it should change if a mouse, rather than a keyboard, is used. If controls only updated when one moved to a different field, then people would probably not get so confused. But that is not how other browsers, and most UI systems, actually work. Intuitively, a field changes when its value changes, not when it loses focus. And as I understand it, other input types in Firefox (e.g. radio buttons) do actually trigger onchange events as soon as they change. As for the "enter" key triggering an onchange event: the "enter" key is nowadays typically used to submit a form (except in multi-line text fields). Reasonable UI programming is going to want to handle field changes long before a submit action is launched. Perhaps the "onchange" event handler should be renamed to whatever acronym would best reflect "on change if you also deselect the field or press enter or change the field with a mouse or set the size to greater than one and it probably helps to cross your fingers and hope to die". So, honestly, the word "logic" does not spring to mind here. The word "quirk" fits the situation better. And it is dealing with browser quirks that makes writing portable HTML a nightmare.
You need to log in before you can comment on or make changes to this bug.