If presented with a select-one list and the mouse is used to select an item the onchange event fires. However if focus is given to the control (mouse or tab) and the keyboard is used to navigate the list (arrow keys, etc.) the list item changes (i.e. selectedIndex), but the onchange event does not fire. Please see the example at the URL above The behavior is exhibited in both the 1.0 release and the nightly build I just installed. Here's what help|about provided: Mozilla 1.1b Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020721 Curiously the problem is not present in my version of Netscape, here are the details from that: Netscape 6.2.3 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3
We have a fixed bug 110800, where exactly the opposite thing (i.e. current beahvior) was requested. ==> WONTTFIX Please read all the comments to bug 110800 before placing an objection!!! Also, note the bug 150759 for some clarification. If you agree with the reasoning behind the two, please mark this VERIFIED.
I don't necessarily agree with the reasoning since it flies in the face of every other browser vendor, but I have been to sites that use a select-one for navigation and it is frustrating to change pages 'accidently'. I don't often use the keyboard to scroll a page's contents, I prefer the wheel on the mouse, so I can't really agree or disagree with the originator of bug 110800. For my purposes I have created a document wide keydown event handler to provide functionality similar to IE, Opera, NS4, NS6 so I'm OK. If you have the time, do you all have an event to fire onchange similar to IE's fireEvent(); I only ask because my keydown event handler could be made more robust... Y'all have bantered this one around long enough so I'll let you go. Thanks for getting back to me so quickly. =)
I've given it some more thought and I'd like to add a comment or two about this issue. As a developer I am a disturbed that I cannot rely on a consistent event model between browsers. Whether that event model is flawed or not is open to discussion. The originator of bug 110800 makes the point about the semantics of making a change and when the event should fire. I contend that the web developer has purposefully chosen to use the onchange event for their navigation. If they wanted the user to make a choice and then do something else to trigger the event they could easily put a button next to the select-one that triggers the change to the new page. Perhaps the web developer didn't think about users who use arrow keys, but that's a usability problem with the website in question not a problem with the event model. The index changed, therefore onchange should fire... shouldn't it? The originator of bug 110800 sounds to me like he is coming from the perspective of a user. If that's the case I would think his bug could have been addressed through a preferences-type screen. By making the change to the core event model you are affecting everyone; developers, users, etc. and they, like I, are probably unaware of your decision to change the event-model. If the resolution he sought was provided via a preference everyone could be satisfied and no one would be caught off guard.
Reopening to dup.
*** This bug has been marked as a duplicate of 126379 ***