User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:188.8.131.52) Gecko/20070309 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:220.127.116.11) Gecko/20070309 Firefox/18.104.22.168 OnChange in <select> doesn't work if key presses are used to change <option> rather than the mouse. Reproducible: Always Steps to Reproduce: 1. http://www.webmonkey.com/webmonkey/98/04/index3a_page10.html 2. Use mouse to select different values in first <select>. Observe second <select> being altered dynamically by JS - this is because the onChange of the first <select> is being fired. 3. Use keypresses to select a different <option> in the first <select> - second <select> isn't altered, onChange isn't being fired. Actual Results: OnChange isn't fired Expected Results: OnChange should be fired
I wonder if this is really a bug or not. This works fine for me by selecting the <options> and pressing the return key. Should the events also be fired by selecting the items with up/down key?
No, they should not. Because of up/down key is like mouseOver/mouseOut events. And actually onChange must be fired when select.value is changed. It changed when you pressing return key or mouseClick --> INVALID
selecting the items with up/down key is cause to fire onSelect event onChange actually must be fired when you select item already and not while selecting it
For key press changes the workaround is to use the "onKeyPress" event.
Confirmed here. This bug can seriously mess-up forms using ajax form-element-updating with the 'onchange' event. The value is changed, but nothing is fired after mouse-clicking or hitting 'enter'. Do we need to submit this bug again for FF3?
Bug exist in FF3.0.5.
Bug exists in FF3.5.2. The expected results are probably inferred from IE. Otherwise, this behavior doesn't exist in FF, chrome, safari and since so forth. This would be a neutral decision in either cases. At one hand, FF behavior is more versatile, that you can just "view" the other options of the list prior to fire the change event, while on the other hand its ease of access to bring about the change via js/ajax by pressing least number of keys. Its more likely to be a Firefox style rather than a bug.