rashid100;10940939 wrote:But when u come in select options via tab and then use Up and Down arrow keys the onchange event did not call the function its call when you lost the focus of select options.
That's because there is no onchange event in this case. At least IE8 recognizes this, and while I have no idea what 5.5, 6, 7 did, you should NOT rely on this behaviour. In fact, you should do whatever you can to prevent it.
Assume I am using tab and arrow keys, for whatever reason. I get to a select box with a few hundred values, such as a list of countries. While I may use 'S' to get to the first country starting with S, I will still have to use the down arrow key several times to get to my country. Why would you wish to consider the intermediate values as an onchange event. The value was "Please select" when I entered the control, and when I leave it, it is "Sweden". There is no purpose at all to regard the control as having had any of the 28 other countries, from Saint Barthelemy to Swaziland as actual values.
Assume I'm performing the same operation as above, but using a mouse instead. I still click 's' to avoid excessive scrolling, but then I move the mouse pointer over the select element and start scrolling the mouse wheel. Should the values the mouse pointer passes fire onchange events?
I enter a text box and start typing away. abcdefg... Should there be an onchange event for a, another after ab, a third after abc (hint, there is not).
<input type="text" name="first_name" class="first_name" id="first_name" onchange="go(this.value)"/>
So, if there are indeed browsers firing onchange events for every arrow key move in a select, I recommend altering this behaviour by using a combination of onfocus to store the initial value, and onblur to check if the value has changed since then and if so, treat this as an onchange event. For the mouse, you'd have to use combination of onfocus, onclick and onlostfocus, where onclick does the same thing as onblur, but also sets the stored value just like onfocus did.