380384 - Key press in <select> doesn't fire onChange when changing <option>

Status: RESOLVED DUPLICATE of bug 126379

(Core :: DOM: Events, defect)

Description

[Stephen Smith]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

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

Comment 1

[Thomas Verelst]

Confirmed.

Comment 2

[bmuskalla]

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?

Comment 3

[Eugen Konkov]

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

Comment 4

[Eugen Konkov]

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

Comment 5

[Nils Hammar]

For key press changes the workaround is to use the "onKeyPress" event.

Comment 6

[cameron]

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?
 

Comment 7

[Sebastian Czarnecki]

Bug exist in FF3.0.5.

Comment 8

[Adeel]

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.