6.34 KB, text/html
Browser, not engine ---> Event Handling Dan: could you attach a reduced testcase to this bug via the "Create a New Attachment" link above? This should be of the minimum size needed to exhibit the bug; thanks. Also - have you tried a more recent build than 20020826? Perhaps this is something that is fixed in more recent builds -
This is done on purpose to allow people using the keyboard or scrollwheel to actually select the option they want instead of having onchange fire on every option along the way. This is identical to the way a text input's onchange does not fire as you type in it. The onchange _does_ fire if the <select> loses focus or if the user presses enter to indicate that she is done changing the value.
*** Bug 178727 has been marked as a duplicate of this bug. ***
> is when you are redirecting based on the selection Which is what at least 90% of onchange handlers on <select> actually do in the real world. The next 6-7% run data-validation code, which should not be run until the user has actually made a selection. Users who are using key nav (who were the people that _requested_ this change, overwhelmingly) know that hitting enter will trigger the onchange, if any.
The selection changes when a user "arrows" through the options. My opinion is that onchange should be fired because the change has indeed occurred. This new behavior not only breaks functionality that has existed for years but also creates an incompatibility with IE. I can understand the desire to have the new behavior in some cases, but I think the addition of an attribute to toggle the behavior is a better solution than a wholesale change in behavior. I don't think one should have to write compatibility code just to support such basic functionality equally in all browsers. Boris: Your message did not address the issue of my attribute proposal. What are your opinions on that matter? Just seems to me if Moz can have blink it can have an extra attribute on some form elements as the attribute could appease everyone whereas blink just makes them mad ;).
I think that the attribute proposal would be best brought up in the relevant newsgroups, not here, where I'm the only person seeing it.... Keep in mind, the change is made for the benefit of _users_ who find the current behavior of IE unbearable. It's as simple as that.
I am new to bugzilla, but I hope we are not the only two seeing this discussion. This is assigned to someone with a netscape.com email address and the reporter seems to feel the same way that I do -- that the new functionality is what is broken and unbearable. I am both a developer and a user. It is _broken_ in its current state.
Ok, I was wrong. Phil is also seeing this. joki quit from netscape about a week ago, so I can guarantee that he's not seeing this. I'm serious about the newsgroups; the decision to change the behavior was made by the keyboard nav and form controls component owners, not by events in any case.
Boris, What newsgroup should I participate in? I am posting this here for the benefit of anyone with the same question in the future. Thanks for your guidance on this issue.
For this? I'd suggest netscape.public.mozilla.accessibility
This is a dup of bug 126379.
*** This bug has been marked as a duplicate of 126379 ***
>I believe the event should be fired when the selection is changed with the >keyboard. For that matter, I think text inputs should too. Try using the oninput attribute. Oninput fires whenever you change the text in a text box, while onchange only fires when you're done editing it. Mozilla only supports oninput for text inputs, but I think it would make sense to make it work for <select size=1> as well.