bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
130298, 137055, 154877, 158551, 161551, 166829, 169867, 177580, 178288, 189973, 193994, 194403, 198510, 199881, 216556, 225699, 229424, 230652, 231712, 234893, 242901, 254573, 256157, 261526, 265389, 268203, 272571, 274388, 280659, 285145, 288187, 288300, 290590, 296125, 303890, 308008, 353968, 380384, 508242, 807948, 969068
When you change the selected item with the mouse, the text changes (the JS is called). When pressing key down and up (looping though the select box), this onChange is not called. Build ID 2002021708, works in IE
Chris, do you know who should own this?
Assignee: aaronl → saari
See bug 110800, wontfix?
The script on the page at the URL above does work. Select an item, tab to move the focus to the button and the text changes. http://www.w3.org/TR/html401/interact/scripts.html#adef-onchange -- <q>The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus.</q> Definately should be wontfix.
wontfix it is
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
*** Bug 154877 has been marked as a duplicate of this bug. ***
*** Bug 137055 has been marked as a duplicate of this bug. ***
*** Bug 130298 has been marked as a duplicate of this bug. ***
*** Bug 158551 has been marked as a duplicate of this bug. ***
*** Bug 161551 has been marked as a duplicate of this bug. ***
*** Bug 166829 has been marked as a duplicate of this bug. ***
mass-verifying Wontfix bugs. mail filter string for bugspam: Tursiopstruncatus
Status: RESOLVED → VERIFIED
*** Bug 169867 has been marked as a duplicate of this bug. ***
*** Bug 178288 has been marked as a duplicate of this bug. ***
*** Bug 177580 has been marked as a duplicate of this bug. ***
*** Bug 189973 has been marked as a duplicate of this bug. ***
*** Bug 193994 has been marked as a duplicate of this bug. ***
*** Bug 194403 has been marked as a duplicate of this bug. ***
*** Bug 198510 has been marked as a duplicate of this bug. ***
*** Bug 199881 has been marked as a duplicate of this bug. ***
*** Bug 216556 has been marked as a duplicate of this bug. ***
*** Bug 225699 has been marked as a duplicate of this bug. ***
*** Bug 229424 has been marked as a duplicate of this bug. ***
*** Bug 230652 has been marked as a duplicate of this bug. ***
Two comments: Firstly, there is a problem here with consistency. This bug has been marked "wontfix" because the w3c recommendation says the onChange event should only happen when the control loses focus. However, if I change the SELECT with my mouse, it doesn't lose focus, but I still get the event, which is inconsistent with the currently displayed behaviour with the keyboard. Secondly, might I be so bold as to suggest that the w3c recommendation is WRONG on this one? It is only a recommendation, they are not infallible, and the sheer number of duplicates for this bug shows that the behaviour of this component is _not_ intuitive. Have there been any bugs complaining that changing a SELECT with a mouse produces an onChange event even though the control still has focus, and that this is inconsistent with the w3c recommendation? No. Because it makes sense that when a SELECT is changed, an onChange event is fired, regardless of any focus issues. At any rate, may I petition that you please don't leave this control with its current incosistent behaviour.
*** Bug 231712 has been marked as a duplicate of this bug. ***
*** Bug 198510 has been marked as a duplicate of this bug. ***
*** Bug 234893 has been marked as a duplicate of this bug. ***
As well as the difference pointed out in behaviour between selecting a value with the mouse (wrong according to W3C's spec) and with the keyboard (correct as per the W3C's spec), the behaviour of the onchange event of radio buttons is also inconsistent. With radio buttons the onchange event fires *before* focus is lost. If you've marked this as WONTFIX, and are sticking by this, then the following list may be of use so as the inconsistencies in conformance to the standard can be ironed out: Input Control onchange conforms to HTML 4.01 spec ------------------------------------------------------ select Yes (when using keyboard to select value) select No (when using mouse to select value) radio No checkbox No textarea Yes text Yes password Yes In all the non-conformant cases, the event is fired before the element loses focus. Personally, I agree with comment #24 and think that the W3C got things wrong with the onchange event description. They already define an onblur event if someone wants to take the focus of an element into account!
*** Bug 242901 has been marked as a duplicate of this bug. ***
*** Bug 254573 has been marked as a duplicate of this bug. ***
*** Bug 256157 has been marked as a duplicate of this bug. ***
(In reply to comment #28) I agree with this poster; the behaviors seem to inconsistent in regards to onChange and onBlur. In this case, I believe Internet Explorer got it right, triggering the onChange even when being changed with a keyboard device.
(In reply to comment #33) this is exactly what many web developers expect to happen. why should an onchange be triggered onBlur but only if one uses the keyboard but not the mouse ?
most pages i see do onchange="window.location=..." which causes the keyboard navigation to get hosed. this is wontfix and should remain so.
(In reply to comment #35) > most pages i see do onchange="window.location=..." which causes the keyboard > navigation to get hosed. this is wontfix and should remain so. A SELECT element with an instant location navigation via onchange has always been a poor design choice. There are plenty of better reasons to use an onchange behavior more consistant to what IE has been doing all along, such as the examples I gave above. This shouldn't be marked "WONTFIX" -- look at Comment #28 for a chart detailing how inconsistent Firefox/etc. is at handling the onchange event.
(In reply to comment #36) > > A SELECT element with an instant location navigation via onchange has always > been a poor design choice. [snip] > > This shouldn't be marked "WONTFIX" -- look at Comment #28 for a chart detailing > how inconsistent Firefox/etc. is at handling the onchange event. I with agree that the current behavior in Mozilla is funky and should be changed to the way other browsers behave. I have heard the argument about redirection before. Redirecting on an onchange is usually a bad idea. So, Mozilla contains a serious functionality change basically to make a poor design less annoying? I also agree that the W3C missed the mark on this one. From all the traffic I have seen regarding this bug and it's dupes, it seems that the vast majority of users don't like the behavior as it is and all we usually get is a blunt "wontfix" from the Mozilla developers (usually with a mention of the W3C recommendation or the redirection example). It kind of feels like we're being ignored.
*** Bug 261526 has been marked as a duplicate of this bug. ***
*** Bug 265389 has been marked as a duplicate of this bug. ***
*** Bug 268203 has been marked as a duplicate of this bug. ***
*** Bug 272571 has been marked as a duplicate of this bug. ***
I know this bug is still a WONTFIX, however i might have a work arround for all those ppl having problems with Mozilla's behavour with the onchange on select form fields. I have just discovered, that the onchange is triggered when the keyboard navigation is used, but only if the size attribute of the selectbox is > 1 Example (won't trigger onchange before the select looses focus): <select onchange="alert(this.selectedIndex);"> <option value="0">zero</option> <option value="1">one</option> <option value="2">two</option> </select> However, this will trigger the onchange event when the keyboard is used (this is tested with FF 1.0/Suite 1.7.3 on W2K: <select onchange="alert(this.selectedIndex);" size="3"> <option value="0">zero</option> <option value="1">one</option> <option value="2">two</option> </select> Whoever is responsible for this bug. _please_ reconsider the WONTFIX flag. Whatever if W3C got this wrong or the implementation is wrong doesn't matter. the behavour is inconsistent (see comment #28), it does not behave as web developer would expect it, it does not comply with all the implementations of other browser (hence, even NN4 did trigger an onchange when the keyboard was used). In fact, the onchange is only called onblur when a user uses the keyboard to navigate trough a selectbox with size 1. In all other cases (mouse, or size >1) the onchange is actually triggered on-change instead of onblur.
*** Bug 274388 has been marked as a duplicate of this bug. ***
*** Bug 280659 has been marked as a duplicate of this bug. ***
*** Bug 285145 has been marked as a duplicate of this bug. ***
*** Bug 288187 has been marked as a duplicate of this bug. ***
*** Bug 288300 has been marked as a duplicate of this bug. ***
*** Bug 296125 has been marked as a duplicate of this bug. ***
*** Bug 297310 has been marked as a duplicate of this bug. ***
*** Bug 290590 has been marked as a duplicate of this bug. ***
*** Bug 308008 has been marked as a duplicate of this bug. ***
Summary: Select onChange not called using down arrow key → Select (size=1) onChange not called using down arrow key
*** Bug 308008 has been marked as a duplicate of this bug. ***
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Assignee: saari → aaronleventhal
Status: REOPENED → NEW
QA Contact: bugzilla → keyboard.navigation
cc hixie, who is re-standardizing onchange and standardizing oninput in http://whatwg.org/specs/web-forms/current-work/.
> * Keyboard-bound users do have a way to work around sites that use dropdowns > for navigation, even if it isn't very discoverable. They can also, more discoverably, work around sites that use this sort of thing for DHTML... Note that I've observed no decrease in the frequency of navigation dropdowns.
One possible solution, which I think would be the most solution most consistent with http://whatwg.org/specs/web-forms/current-work/#the-change, would be to add support for <select oninput>, evangelize sites that use DHTML for forms to use oninput in addition to onchange, and re-WONTFIX this bug.
I'd be happy to do that, I think.
If the user drops the drop-down and selects an option then rolls it back up (all using the keyboard) then onchange should fire when the drop-down is rolled back up. However, we can't do that if the user is just typing into the select or using up and down without the drop-down since we have no way to determine when the selection finished in that scenario. The above paragraph is intended to be consistent with what the WHATWG spec says. HTH.
In repsonse to the previous comment, I think the event is very clearly 'onChange', as opposed to 'onEndOfSelection', if you get my drift. As a programmer, I would expect an onChange event to be fired every time the value of the input is changed, regardless of whether the user is still moving through or typing or whatever. If I wanted to only perform my specific action when I'm sure the user has stopped changing the value, I'd take responsibility for that by setting a timer for about a second to execute my action and cancelling it if the value changes in that time.
> since we have no way to determine when the selection finished in that scenario. When the control is blurred or the user hits enter. That's when we fire onChange now. > every time the value of the input is changed, regardless of whether the user That's not how text inputs work, now is it? For much the same reasons. There's a difference between the user being in the process of changing the value and the user actually changing the value. > I'd take responsibility for that Only if you actually stop to consider that not everyone uses the Web with a mouse. If you stop to think about that, kudos; experience shows that you're one of a very very small number of such designers.
> > since we have no way to determine when the selection finished in that > > scenario. > > When the control is blurred or the user hits enter. That's when we fire > onChange now. Oh, I didn't know we did it when you hit enter (I figured that submitted the form). Ok, that's cool. In that case IMHO this bug should be closed, in favour of a separate bug to implement oninput="" on <select>.
I reported this bug a long, long time ago, although I think my bug was deleted in favor of someone who had reported it before me. The original web page that made me irritated by Mozilla's behavior was deleted as well, so I could not provide a link to it. However, I noticed that the exact same page is back up. http://www.kcfn.net/bible-memory.html?v=2 It irritated me very much that I COULD NOT use the arrow keys to navigate instantly to the next verse. This is contrary to the opinion of people who have said users will not desire to be redirected. I'm pointing this out because after reading many comments, I see there are only two reasons that onchange is not fired by using the arrow keys in a select element. (1) The W3C says that onchange must be fired only when focus leaves the element. (2) People believe that onchange may be fired prematurely when the user has not "completely" selected their final choice. This will be a source of irritation to the user when the result of their action is a complete change of state (such as being redirected away to another web page) which does not allow them to retain the ability of finishing their selection. Note that error (2) only becomes significant in the case where the results of the first selection make it inconvenient to choose another selection. The most severe instance is obviously one where a permanent, immutable decision (e.g., causing an email to be sent) is made when the onchange event handler is fired. In response to error (1), the wording of the W3C's proposal (they have standardized the definitions, but in and of the fact that they did not implement everything, their standards may only be regarded as significant proposals for the implementation of web standards) is somewhat vague. Each select option can also be loosely viewed as an "element," and if "focus" may be thought of as being directed to a sub-element of the select menu, then clearly focus leaves the old option and lands upon the new option, each time that the user clicks or uses arrow keys to change the selected option. But this is nothing but arguing about terms. It's useless argue about terms, because similar things have been said by almost everyone. I am not "for" or "against" this bug. However, it is more important to think seriously about the results of error (2). We can also argue about cases where arrow keys ought to trigger the onchange action. I am aware of cases both in favor of and against "fixing" this bug. There have been film exposure calculators written for Kodak, where f/number, exposure value, film speed, etc., are calculated proportional to each other, and using the arrow keys is the way to go--not because I say so, but because this is the way people use it. In Mozilla the calculator does nothing, until the user mysteriously "activates" his set of exposure settings, by clicking into some empty space in the web page, in order to remove focus from the select element where his last choice was made. This behavior is perfectly "workable," although several times slower than using the arrow keys to instantly calculate the results and compare several camera settings in close succssion. I wrote one of those calculators in 1999, and you can imagine how the users have been affected as Mozilla originally calculated by using the arrow keys, and then did not. Presently, I am not affected by whether this web page still works or does not work. What I am presenting by this example is also a fairly weak argument. The desired behavior is not being "blocked" by Mozilla, but rather the user has to understand how to get around it by doing something that to the uninitiated would seem like waving a magic wand. But the most important thing I would like to bring up is a dicussion of the primary reason why people don't want onchange behavior to be triggered by mouse keys. Much of this discussion has been lost, because of Bugzilla's semantics of "closing a bug"--the discussion in a closed bug is not brought inline to the discussion of the bug that it was closed in favor for. People are being directed by poorly designed scripts into being committed to the first course of action which happens to occur by selecting the next or previous element using the arrow keys. This happens because it was not clear to the user that the select element was a "live" selector. Live selectors were growing very rapidly in popularity, but then I noticed that they sort of bumped into a ceiling. Bad scripts made bad use of the instant action when instant action really wouldn't have been the best thing. It isn't right just to put an onchange handler into something that really needs a submit button. A case in point is sending an email. Email people should know that a select menu isn't the right way to submit the email. Most of them are smart enough to design their web pages the right way. A much more difficult case is when a form designer has left out a submit button altogether, and somehow unexpected conditions are reached. It is not impossible for a user to be left with a select menu that has his desired selection, and yet he cannot submit the form, without changing the select menu, which results in his submitting the wrong selection! Thus, it becomes clear that submit buttons need to be used for submit buttons. A stylish web page takes a risk if it uses a menu for the purpose of its submit button. However, live selectors became something that web designers grew wary of, because they turned out to be wrong for most people. Even menus where instant action was more desirable began to grow too long. It was hard for the user to pick the right item. There were so many items to choose that the instant action usually became the wrong action. In my opinion it would be better to leave nasty web designers hangning, with all of their incorrect designs. Somehow people think that they can get a good result without changing their flawed designs. It would be ridiculous to "fix" this by implementing oninput, and insane to implement oninput for the sole purpose of "fixing" this. People would continue doing their designs wrong. Whatever the behavior is when a user clicks on a select item and chooses the selection above or below, should be the same as the behavior when the user clicks on a select item and uses the arrow keys to select the item above or below. If the onchange event handler fires, then a user who uses the arrow keys to make his selection will be precluded at this point from making any other selection. Only someone who selects his choice with the cursor will be able to choose something that is not adjacent to the item which is currently selected. Even so, the behavior is consistent. Every user has a right to do wrong or right, and have the results of his own actions be the result of his own actions. In my case, I actually wanted to have a permanent change happen (loading the next Bible verse) when I clicked on the select menu that showed verses, and used the down arrow to select the next one. I was unhappy that it did not happen, and the poor design of the web page meant that I would have to use a "magic wand" and click elsewhere on the page, in order for the onchange handler to be invoked. This defeated the purpose of the select menu, which was instant convenience. It didn't matter if I was redirected, because the permanent change wasn't a significant change. I don't think that designs which make a significant decision should be using an instant handler device. Therefore, it must be resolved whether an instant handler is useful, such as a live selector menu. If it is useful, and if Mozilla can trust people on the Internet to design web pages (judging the intent of software developers or software users is not the role of an organization, anyway) and take the consequences for them, then a live selector ought to be live, either by the cursor or by arrow keys.
After making several posts to w3c groups regarding this issue and doing some more real world hacks around this event functionality, I tend to agree with the Mozilla team that this issue is not a bug and Mozilla's model is correct, logical and even functional (onblur and enter key fires event). For those who have issues with this, train users to hit enter key when selection is made and make sure you set onsubmit event of form to 'return false' to capture any auto submits. Thanks for holding out Moz dudes. Keep up the good work! ...Removing myself from this bug... JsD
(In reply to comment #64) > After making several posts to w3c groups regarding this issue and doing some > more real world hacks around this event functionality, I tend to agree with the > Mozilla team that this issue is not a bug and Mozilla's model is correct, > logical and even functional (onblur and enter key fires event). I'm sory, but you're simply plain wrong. This is a English issue, not a standards issue. What does 'on change' means in english?! I'm portuguese, so I may not fully understand the meaning... And there's also incosistencies in behaviour. Why making something with the mouse has a different behaviour than doing with the keyboard? "f I change the SELECT with my mouse, it doesn't lose focus, but I still get the event, which is inconsistent with the currently displayed behaviour with the keyboard." > For those who have issues with this, train users to hit enter key when selection > is made and make sure you set onsubmit event of form to 'return false' to > capture any auto submits. Just plain wrong. Users wan't to change and don't press enter, they don't care about any technological standards. If you said use the onChangeValueWithKeyboard event, that would be the correct answer. People wan't to change with the keyboard or the mouse and have the same behaviour. People don't care about technological problems. Standards?! Scew them if they don't know the meaning of the words! I Repeat, it's an ENGLISH problem not a technological one...
> This is a English issue, not a standards issue. Um. NO. It's a standards issue. > What does 'on change' means in english?! It's not well-defined, because human languages are not very good at having precise meanings attached to words. For example, what does "change" mean? Why can people ever have an argument about whether someone has "changed" over the years? > Why making something with the mouse has a different behaviour than doing with > the keyboard? Because a priori the process of selecting an option with the keyboard is different from doing so with a mouse. WITH A MOUSE YOU DON'T HAVE TO GO THROUGH ALL THE OPTIONS IN BETWEEN THE DEFAULT ONE AND THE ONE YOU WANT. People seem to miss this point, for some reason I do not understand.
(In reply to comment #66) > > Why making something with the mouse has a different behaviour than doing with > > the keyboard? > > Because a priori the process of selecting an option with the keyboard is > different from doing so with a mouse. WITH A MOUSE YOU DON'T HAVE TO GO THROUGH > ALL THE OPTIONS IN BETWEEN THE DEFAULT ONE AND THE ONE YOU WANT. People seem to > miss this point, for some reason I do not understand. Then, to have a equivalent behaviour, at least fire the onChange after half a second or so have passed without the value changing... I won't even argue about the meaning of change but I believe that some event should be triggered when the user changes the selection. If not onChange, make a onKeyboardChange event so developers can make sites that work the same in Mozilla and in IE... Ask some user what he wants: - A discussion of what onChange means or a site that behaves as expected?
I filed bug 312094 for adding support for <select oninput>.
This issue has annoyed me for a long time. Mozilla does behave differently than any other browser I have ever tested, but I understand the importance of trying abide by standards. But I don't like hearing the argument about selects used for navigational redirection because I don't think such a common control should have it's functionality determined by one common use. Here's an idea that I haven't heard mentioned before: Why not make the onchange event work like all other browsers when quirks mode is enabled and make oninput available in standards mode? In quirks mode you could still use onblur to achieve the same functionality that Mozilla's current onchange provides. Wouldn't this satisfy most people and at the same time be even more Mozilla-like than it is now?
> Then, to have a equivalent behaviour, at least fire the onChange after half a > second or so have passed without the value changing... Might not be a bad idea. File a separate bug on this, and let's have the accessibility folks check out how that works for disabled users (many of whom who have to use the keyboard or equivalent, and whose concerns we need to make sure to address when dealing with keyboard functionality)?
(In reply to comment #70) > > Then, to have a equivalent behaviour, at least fire the onChange after half a > > second or so have passed without the value changing... > > Might not be a bad idea. File a separate bug on this [...] I'm sorry but I don't understand if you're being ironic or not... Supposing you're not, I don't think I should file another bug. This bug is about triggering the onChange event when using the keyboard and I'm suggesting the event should be triggered 500ms after the user making a change...
I don't like the "trigger 500ms after" idea. That won't give keyboard users enough time to read each item as they arrow through a list.
(In reply to comment #72) > I don't like the "trigger 500ms after" idea. That won't give keyboard users > enough time to read each item as they arrow through a list. What about trigger after 750ms, or trigger after 1sec. The ideia in itself is trigger the event after a given amount of time has passed without any more changes. The given amount of time is irrelevant for now as it can be easially be a configuration parameter defaulting to some given value...
> Supposing you're not, I don't think I should file another bug. I'm not being ironic, and suit yourself. As a separate bug, it might get fixed. As part of the spam-fest that is this bug, it never will be -- I suspect people have filters in place to automatically delete any mail with this bug number in the subject. If you do file this new bug, please do cc me on it.
13 years ago
Depends on: 312162
(In reply to comment #74) > I'm not being ironic, and suit yourself. As a separate bug, it might get fixed. > As part of the spam-fest that is this bug, it never will be -- I suspect people > have filters in place to automatically delete any mail with this bug number in > the subject. Sure feels that way. Is the amount of traffic on this not an indicator that the current functionality is not quite right? FWIW, I don't like the trigger after x seconds either. That's just odd. It changed or it didn't. I would like to get some feedback on my quirks/standards mode idea though.
> x seconds either. That's just odd. It changed or it didn't. I would like to > get some feedback on my quirks/standards mode idea though. The differences between the two modes needs to be reduced. Products which contain divergent feature sets tend to be unsuccessful.
(In reply to comment #76) > The differences between the two modes needs to be reduced. Products which > contain divergent feature sets tend to be unsuccessful. Mozilla can't just throw quirks mode away. It exists for a good reason and I think this is an opportunity to utilize it. But as a developer I certainly do hope that one day everyone will support standards. Coding to standards is really nice... until you look at the page in IE ;-).
*** Bug 303890 has been marked as a duplicate of this bug. ***
If you think about it... people who don't use a mouse will be forced to use the keyboard to look through SELECT items. If cycling through the items causes the onChange to fire.. .those keyboard-only users will have a very difficult time.. especially if the onChange causes a form submit or other form elements. I hate to say this.. but I agree... ENTER should trigger the onChange. Therefore the WC3 standard is correct and this bug is INVALID. Here is a simplfied example of this in action: http://www.imperial.cc/onchange.htm
(In reply to comment #79) > If you think about it... people who don't use a mouse will be forced to use the > keyboard to look through SELECT items. > > If cycling through the items causes the onChange to fire.. .those keyboard-only > users will have a very difficult time.. especially if the onChange causes a > form submit or other form elements. Cycling through the values should not make a form submission. Submit buttons should do that :p > I hate to say this.. but I agree... ENTER should trigger the onChange. > Therefore the WC3 standard is correct and this bug is INVALID. I'm sorry but I disagree with you. The value changed, thus onChange should be called. > Here is a simplfied example of this in action: > http://www.imperial.cc/onchange.htm 2 Comments: - Change the size of select box to 2 and explain why is acceptable to trigger the onchange on changing with the keyboard. People still have to use the keyboard to cycle through the options. - I've opened with the browser used by around 90% of the people and it had the behaviour that at least those 90% expect: Changing the value with the keyboard triggers the onChange event. So, for at least 90% of the Web users Mozilla has a bug.
this bug is marked wontfix for a long time. i guess adding protest comments doesn't change that. it's a matter of fact that mozilla's onchange doesn't fire onchange and therefore is incompatible with (probably) all other browsers just becasue some webedevelopers use sloppy techniques i do not think such a radical change in functionality is justified. Sad to say that this problem makes firefox less usable than it could be actually.
Is there an extension that changes the behaviour of onChange in the way people are proposing? If not, is it because it's not possible to do this in an extension? If so, maybe a new bug should be filed to request an enhancement to make that possible.
My 2 cents: I'm in favor of changing this so that we do fire OnChange also when selecting a new value using the keyboard. This is what IE6/XP, IE7b2/XP, all four combinations of Opera8/Opera9 on XP/Linux, Safari(nightly)/OSX 10.4.6 do, which makes me comfortable that sites don't have obstructive OnChange handlers in general. Being incompatible is likely more of a problem (as this bug seems to suggest). (FYI, "Patch rev. 2" in bug 231830 also fixes this bug)
Assignee: aaronleventhal → mats.palmgren
OS: Windows 2000 → All
> which makes me comfortable that sites don't have obstructive OnChange handlers > in general You're way too optimistic. I run into such handlers all the time, whereas I've never run into issues due to the current Gecko behavior -- just hit enter once I have the thing I want selected.
(In reply to comment #84) > I run into such handlers all the time... Do you have an example? (or more) - I'd like to understand why those sites does not cause problems for the other UAs I mentioned.
The important point to focus on here is that the Gecko engine is almost certainly the only browser engine to exhibit this behaviour, and likewise almost certainly the only implementation of a combo box to exhibit this behaviour. Every other browser triggers onchange when the text in the display box changes, and this has to be the only logical interpretation of the word "change" in the event name. Yes, some sites abuse the dropdown list, and you get undesirable behaviour. In the same way, some drivers abuse cars, and cause crashes. This does not mean that all cars should be designed to crash. This odd and unusual behaviour by Gecko makes some situations hard to program, so that the user experience for mouse-challenged users in Gecko-based browsers is frustrating for them because they have to keep hopping in and out of the dropdown to see the effect of choosing a different value in the dropdown. This issue has been raised over and over again. It's time something was done about it! The objection to the change is because if someone uses the dropdown as a navigation tool, use with a keyboard can be frustrating because you zap off elsewhere. This is not what a dropdown should be used for: it is a tool for selecting one of a list of values (Note: NOT destinations).
I agree with Gecko with the current standard. Moreover, I see that gecko is supporting "Typing in the combo box" to select any item by spelling from the dropdown list. I guess this feature is a nice one that everybody would want and has a competitive edge over IE. Also, triggering 'onChange' when using the keyboard while selecting the values in the dropdown, would compromise on the features that are already available like the one above. Pressing 'Enter' key should resolve any issue in the website for which onChange event needs to get triggered. My vote for Wont Fix!
(In reply to comment #87) > [...] "Typing in the combo box" > > Also, triggering 'onChange' when using the keyboard while selecting the values > in the dropdown, would compromise on the features that are already available > like the one above. Explain me as if I'm really dumb... I don't undertand why triggering the onchange would make it stop working. It would probably execute the associated script more times than required but I don't see a problem with that. > Pressing 'Enter' key should resolve any issue in the website for which onChange > event needs to get triggered. It's not the natural behaviour... ALL other browsers don't have this behaviour. Maybe you should start asking yourself why. > My vote for Wont Fix! My vote for Fix It as fast as you can, please.
I agree with those who would like to see this fixed. If a mouse/keyboard action causes the selected item to change, then the onchange event should be fired. It seems nonsensical to think that one could somehow navigate to a select field, cause its contents to change and then submit the form without the onchange event firing. There is an issue, too, with the default behaviour. In IE and the versions of Mozilla/Firefox that I am using, typing an alphanumeric key when a select field has focus causes the first/subsequent option with that initial character to be selected. I have used a script to implement incremental search (so that a second character typed does not replace or override the first, but supplies a second character to the search mask). Supplying an override onchange handler in IE defeats the default behaviour and the incremental search works fine. In Mozilla, however, it works only if you type really quickly. Type slowly and the default behaviour overrides the scripted behaviour. It's as if the default handlers are programmed to sneak in on some kind of timeout (although I could be wrong!). I think that default onchange behaviour should be overriden by programmed onchange scripts. Or there should be a documented way to defeat the default onchange behaviour (e.g. returning status from the onchange handler). CPK Smithies
(In reply to comment #89) > I agree with those who would like to see this fixed. If a mouse/keyboard action > causes the selected item to change, then the onchange event should be fired. It > seems nonsensical to think that one could somehow navigate to a select field, > cause its contents to change and then submit the form without the onchange > event firing. Onchange is fired when the dropdown loses focus, or when you press enter. As far as I know, the onchange event does always fire before the submit event. > There is an issue, too, with the default behaviour. In IE and the versions of > Mozilla/Firefox that I am using, typing an alphanumeric key when a select field > has focus causes the first/subsequent option with that initial character to be > selected. In the version of Firefox I'm using, typing several letters into a dropdown (without waiting too long) does what you want, so you shouldn't need a script to override it.
(In reply to comment #90) > In the version of Firefox I'm using, typing several letters into a dropdown > (without waiting too long) does what you want, so you shouldn't need a script > to override it. Yes, it's that "(without waiting too long)" that is the issue. Who says what is "too long"? And in a way even that is irrelevant. Ordinary users just can't cope with a user interface that does different things depending on the speed at which they type. And I don't blame them one little bit. Imagine a user who is not (perhaps) totally focused on what they're doing, or who is subject to random interruptions. Add the possibility that they are not fast typists. That (I should think) characterizes 99% of web form users. And here we have a user interface that changes behaviour depending on their typing speed. Such a thing could only be designed by people who do not live in the real world. It is not to be wondered at that someone should try to script something more predictable to override that, and the fact that it isn't overridable is, it seems to me, a serious problem given that some designers may need to do special scripting for disabled and slow users, or for special applications. CPK Smithies
(In reply to comment #83) > My 2 cents: I'm in favor of changing this so that we do fire OnChange > also when selecting a new value using the keyboard. This is what IE6/XP, > IE7b2/XP, all four combinations of Opera8/Opera9 on XP/Linux, > Safari(nightly)/OSX 10.4.6 do, which makes me comfortable that sites don't > have obstructive OnChange handlers in general. We lose. There's no point in being odd browser out here. BTW, I'm bugged by this bug too. Boris, if you can identify sites that misbehave if we fix this bug, please list them. If they would misbehave with all the above-mentioned browsers too, they will be easy TE targets. If they are somehow misbehaving only for Gecko (with a fix for this bug), then why? /be
> I have used a script to implement incremental search [...] This bug is about the onchange event. However, it seems what you are looking for is onkeydown. In general, I tend to use onkeydown in addition to onchange if I want Gecko-based browsers to behave the expected way.
(In reply to comment #93) > > I have used a script to implement incremental search [...] > This bug is about the onchange event. However, it seems what you are looking > for is onkeydown. > In general, I tend to use onkeydown in addition to onchange if I want > Gecko-based browsers to behave the expected way. My script does use onkeydown. On reflection, perhaps my problem should be reported separately. In essence, it is primarily that scripted onkeydown behaviour doesn't defeat the default onkeydown behaviour in Mozilla/Firefox, and secondarily that ordinary users find the default behaviour unpredictable.
(In reply to comment #85) > Do you have an example? I'll be happy to dump some in this bug as I run across them. Of course that requires browsing with non-Gecko browsers, which I don't do very much anymore. I did have 3-4 very popular examples a few weeks ago, but since I wasn't cced on this bug I didn't realize people actually wanted them... > I'd like to understand why those sites > does not cause problems for the other UAs I mentioned. Who ever said they don't? To make these sites usable with a keyboard in non-Gecko browsers, you have to keep remembering to alt-down before making your selection instead of just arrowing to it. It's a royal pain in the behind -- you either have to memorize which sites are the sucky ones, or arrow down, get a nasty shock, hit back, and try again. I suggest you try browsing the web for a day or two with IE using only the keyboard. Make sure to hit lots of popular game sites and other top100 stuff and such when you do. Brendan, site authors have zero interest in actually making their sites usable for keyboard users in my experience. Good luck evangelizing them; we've had no luck with that sort of thing in the past. If you feel that we should switch the default behavior to be compatible with other browsers, I could perhaps buy it if there is an accessibility option to have the current behavior. Of course that involves us maintaining (and testing!) two different codepaths, which is rather unfortunate.
OK, I decided to try using Opera for a day. About 5 minutes later, while planning a trip, I run into <http://transitchicago.com/maps/bus/bus.html>. Try to get the bus schedule for the #57 bus, say. More reports as I run into them.
Another 2 minutes after that, I run into <https://webmail.mit.edu/> while looking for some old mail. Unfortunately, this requires a login, but if you have access to some other IMP webmail system (<http://www.horde.org/imp/>) I suspect they all behave about the same. There are two comboboxes on that site that have the behavior we're interested in. The first is the "Select" combobox (where you can select "all", "unseen", "answered", "not answered", etc). The second one is the "Mark as" combobox (where you can select things like "seen", "deleted", etc). Trying to use these with the keyboard would typically make you mark all your mail as seen in non-Gecko browsers. I should note that having to type all this up really affects the speed at which I can browse. ;)
OK, I had to stop the Opera experiment, because it kept completely hanging every time it ran into a PDF. I've been mostly dealing with bugzilla since my last comment, and I can report that bugzilla does not abuse onchange... ;)
Ok, I was probably too optimistic regarding abuse of 'onchange'. I'm still in favor of fixing this bug though, then file TE bugs for the broken sites. I think it's worth gaining compatibility in this case. FWIW, http://whatwg.org/specs/web-forms/current-work/#forms-events-model "In [DOM3EVENTS] and [HTML4], the change event is fired on a form control element when the control loses the input focus and its value has been modified since gaining focus. This specification changes these semantics to more accurately reflect the behaviour expected by Web authors. Specifically, for controls implemented with a non-editable stateful UI (e.g. select elements, checkboxes, or radio buttons as deployed in typical desktop Web browsers), the change event shall be fired when the selection is completed, even if the control does not lose focus."
That text depends on the definition of "selection is completed". For example, if I hold down the down arrow key, selection is not completed until I release it. How is pressing the down arrow key a bunch of times in a row different? As I said, if people really want compat I'm ok with it as long as the current behavior remains available to people who actually use the keyboard.
(In reply to comment #100) > That text depends on the definition of "selection is completed". For example, > if I hold down the down arrow key, selection is not completed until I release > it. How is pressing the down arrow key a bunch of times in a row different? We could use a timer, if you haven't pressed and released quickly enough, the selection is complete. My Macbook love affair has been tempered by interaction with similary timer-based magic to disambiguate mousedown-and-sweep-or-drag from mousedown-for-context-menu. Ugh. > As I said, if people really want compat I'm ok with it as long as the current > behavior remains available to people who actually use the keyboard. Pref for a11y seems like the least we should do. But can we do better? /be
Timers are bad for users with physical disabilities.
(In reply to comment #102) > Timers are bad for users with physical disabilities. Including me -- half the time on my Mac, I try to drag something (a mail message to a folder in mail.app, e.g.) and I get the context menu cuz I'm slowing down in my old age. /be
Here's an alternative suggestion: If the scroll box has a (non-chrome) onChange handler attached, then... the initial down-arrow should scroll out the list, like alt-down-arrow now does. It has the benfit of giving the user a visual clue that some immediate action is likely to follow selection. I realized that my initial suggestion would change user experience for people who keyboard navigate, presenting more visual clutter and requiring on extra click on the arrow. This alterative would reduce those cases.
How does your suggestion handle the case where I start typing letters after focussing the drop-down box? Do you still think it should open the drop-down then?
The issue here is not what can be done for Gecko to get around misuse of the dropdown list as a naviagation selector (it's a data input device, nothing else) and behave even more wildly at odds with other browsers. The issue is that the Gecko engine does not have standard behaviour, and that is what should be worked towards. That CNN behaves badly when you use the keyboard on its dropdown boxes is an indictment of the behaviour of CNN's site, and it will do exactly this for users of any other browser engine. This issue should be raised with CNN, who should be taking care to make their site browser-neutral. Where this issue raises problems is when one is trying to script the behaviour of the control and update other parts of a form in response to the change in dropdown selection. The worst issue is if the next field is hidden as a consequence of the value change and suddenly nothing has the focus if you just tabbed out of the control to get the event triggered. The behaviour should be that if the contents of the text portion of the control have changed, the event trips; if one is scrolling through the list in expanded form without yet selecting a new value, it hasn't changed and therefore no event. If one is doing this with a collapsed list using the keyboard, the value has changed and therefore an event should take place. This is surely the most obvious interpretation of the event name?
> The issue is that the Gecko engine does not have standard behaviour, and that > is what should be worked towards. The real issue is what would be best for users of Gecko (and I don't mean website authors here; I mean people using the browser). I'm not sure why there should be a difference between scrolling through depending on whether the <select> is expanded or collapsed; I have yet to see anyone clearly explain to me why these two cases should lead to wildly different behavior.
Agree with #108. In addition I reiterate that it is possible to filter unwanted event firings by hooking them. When they don't fire, there is nothing the UI designer can do. As things now stand, the behaviour is inconsistent, unpredictable and not overridable. At the very least, it should be possible to get the effect the application requires by using appropriate event handlers. Currently it is not. The inconsistency has been caused by too much "clever" programming and second-guessing how designers should or might use select controls. "Clever" programming should be delegated to the page designer and should be confined to his own scripts, not be embodied in the browser and inflicted on the rest of the community!
Agree with #108. In addition I reiterate that it is possible to filter unwanted event firings by hooking them. When they don't fire, there is nothing the UI designer can do. As things now stand, the behaviour is inconsistent, unpredictable and not overridable. At the very least, it should be possible to get the effect the application requires by using appropriate event handlers. Currently it is not. The inconsistency has been caused by too much "clever" programming and second-guessing how designers should or might use select controls. "Clever" programming should be delegated to the page designer and should be confined to his own scripts, not be embodied in the browser and inflicted on the rest of the community!
The issue is NOT what someone thinks would be best for users of Gecko, but what users have come to expect from controls of this type. The experience should be the same no matter what browser or OS-native application they use - and Gecko's behaviour is different from every other incarnation of the dropdown list I have ever encountered. In the bad old days, application interfaces were pretty much unique to each program one used, and when you used a new package you had no idea what to expect would be required to drive. The IBM Common User Access (CUA) standard initiative changed all that and brought order out of chaos, and subsequently software which conformed to that was familiar the first time you used it. This is what we should be able to expect from browsers. Gecko should be brought back to the mainstream, and should behave the way it does in other contexts, be that Web browsers, Windows apps, Macintosh apps, whatever. A dropdown list is an input device, not a navigation tool, and should be used only as such.
Sorry for the double posting earlier - don't know what happened there. Just wanted to address a point in #66: it is incorrect to assume that with a select control, the keyboard forces users to pass through all intermediate steps from the default option to the desired one. Typing letter keys can take one there directly, or (using incremental search) through very few intermediate steps. Of itself, this is neither here nor there; I make this point only to remove a possible justification for inconsistent treatment of mouse and keyboard interaction with the same control. (Which inconsistency would be fine if one could add event handlers to solve it!) (Agree with #112 also.)
Folks, let's not repeat ourselves if we can help it. I'm the perpetrator of select onchange= (with help from front-end hackers, in Netscape 2, the dawn of JS). I think we should change, see comment 92. Authors will change their content to be more keyboard navigable due to Sec 508 in the U.S. FWIW. If there were a way to distinguish cases so that we could do right by keyboard users most of the time, and be compatible by default in the common case -- and without using a timer, that would be wonderful. Otherwise, then how is any amount of keyboard navigation goodness for Gecko-based browser users ever going to spread to other browsers? Boris, from comment 95 it sounds like you would be ok with matching the de-facto standard by default, if there were a pref. Are you still ok with this change? /be
You know what annoys me most about this bug? It's not the bug itself, and it's not the comments or the arguments or the discussion. It's the fact that the Powers That Be™ have already made up their mind, and are not going to be swayed by any amount of arguments, no matter how reasoned and valid. People are going to continue discussing this in here until the end of Mozilla, futilely. That makes me sad.
(In reply to comment #116) > You know what annoys me most about this bug? It's not the bug itself, and it's > not the comments or the arguments or the discussion. Useless comments are more annoying to most people. > It's the fact that the Powers That Be™ have already made up their mind, and are > not going to be swayed by any amount of arguments, no matter how reasoned and > valid. Watch that victim complex. If I'm not a power-that-is, I guess I'm just spamming this bug too. We'll see. > People are going to continue discussing this in here until the end of Mozilla, > futilely. That makes me sad. Want to bet? Useful (I hope) content: What do people think of the suggestion in comment 105, elaborated in comment 107? It was not clearly shot down. Is that possibly the basis for a synthesis that makes most cases work via keyboard as well as mouse? /be
(In reply to comment #117) > What do people think of the suggestion in comment 105, elaborated in comment 107? Seems good to me. At the same time, I'd recommend that entering alpha keys into a select control should also be taken into consideration, and that timeouts should never be used to influence the response of the control to keyboard input.
The entire problem is that Mozilla/Firefox/Gecko behaves differently from any other browser. Comments 105 and 107 do not address this at all; quite to the contrary, they are suggesting to make it even worse, by making Mozilla/Firefox/Gecko behave inconsistently even with itself.
> and that timeouts > should never be used to influence the response of the control to keyboard > input. This would mean that, and soon as you type a wrong character, you are screwed. The time-out exists in other drop-down box implementations to alleviate that problem.
(In reply to comment #120) > > and that timeouts > > should never be used to influence the response of the control to keyboard > > input. > > This would mean that, and soon as you type a wrong character, you are screwed. > The time-out exists in other drop-down box implementations to alleviate that > problem. Yet timeouts are considered an a11y problem (see comment 102). (In reply to comment #119) > The entire problem is that Mozilla/Firefox/Gecko behaves differently from any > other browser. That's not "the entire problem" or we wouldn't have any controversy. Rehashing. The other problem, from the other side of the dispute, is all the broken web sites out there, and how they're unusable when navigating via the keyboard. One way out, which comments 105 and 107 point toward, is to evolve the widget so it works better for keyboard users without breaking the de-facto standard (much). If this is not possible, let's see a definitive proof and I will cut the Gordian knot in favor of de-facto standard compatibility, with a pref for bz and others who are accustomed to Gecko's longstanding behavior. If, on the other hand, some new synthesis of logic could make both mouse and keyboard behavior better according to both sides of the dispute, then let's do that and stop all the repetitive posturing about what "the entire problem" is. /be
I cannot agree with the comment about the de facto standard or broken sites. These statements are valid only in the context of Gecko, and those sites are violating the de facto standard and broken for every other browser, of which IE is still used by the vast majority of users. In other words, those sites are "broken" for the majority of users out there. It's the sites which should be fixed. Bear in mind that Gecko does not exist in a vaccuum. It is one browser in common use, and a minority player, even if a large minority.
(In reply to comment #122) > I cannot agree with the comment about the de facto standard or broken sites. > These statements are valid only in the context of Gecko, and those sites are > violating the de facto standard and broken for every other browser, of which IE > is still used by the vast majority of users. In other words, those sites are > "broken" for the majority of users out there. It's the sites which should be > fixed. That is easier said than done. In the mean time, browsers than can handle both "correct" and "broken" sites, and innovate in ways that add accessibility, can gain market share. Not that Firefox is obviously doing that in this instance, since the benefits that bz cites in comment 96 and comment 97 can't be traded off against the pain that others feel on different sites. My point is that it is often possible to have our cake and eat it here. Firefox 1.0 shipped with Gecko support for "undetected document.all" abusage, and gained market share thereby, without encouraging more bad practice in content. That change scandalized some folks, but it's a rational consequence of game theory applied to minority market share browsers. For this bug, gaining market share is why I say the default right answer is to match other browsers' onchange behavior. But if we can forge a new synthesis that is mostly or entirely compatible, but has better a11y, then we should not miss the opportunity. > Bear in mind that Gecko does not exist in a vaccuum. It is one browser in > common use, and a minority player, even if a large minority. Like, duh. Let's take off the ideological blinders. The de-facto standard is not the last word, or the best way, just because it is a standard. We should match it exactly if we can't find a way to improve it without breaking compatibility (much, or at all). It could be that this is not the bug in which to innovate, and we should focus our energy on supporting the oninput attribute. I'm not going to wait too long for a "new synthesis", and I've already said that I favor us matching other browsers by default if we can't do better. So I would appreciate it if comments other than "me too" and the like focus on whether it's possible to synthesize behaviors into a coherent, mostly-compatible whole. /be
Per: http://whatwg.org/specs/web-forms/current-work/#the-change http://www.w3.org/TR/web-forms-2/#the-change ...the event fires when the selection is complete. In the case of keyboard input, the selection is not complete when the user uses arrow keys. In the case of mouse input, a click does indeed complete the input. If the user with a keyboard opens the drop down, then selects something, then closes the drop down, then the event should fire. The "input" event is closer to what it sounds like people want here. It would fire whenever anything changed at all due to user input.
Brendan Eich: Sarcasm is not a good approach, nor using "duh"-type remarks. It will generally result in a flame war, so inflaming such is not a good idea. I respond in an attempt to engage the intellect, not the emotions. I have no ideological blinders on. My point is that the de facto standard must be followed, and Gecko doesn't do that. I'm not particularly in favour of mucking about trying to enhance the behaviour, and would prefer it to do just what it was originally designed to do. Interface behaviour should be consistent and expectable, and this is a standard interface device. I won't kick against additional features, as long as the thing behaves as I expect it to and the enhancements do not intrude in any way. I would not try to exploit the behaviour programmatically, since that would make my code browser-specific and not browser-neutral. Hixie: The keyboard can be used two ways with a dropdown. Alt+Down arrow in Windows will cause it to open the list, and then the keyboard can be used to select from the list without changing the displayed text value until you press enter, when the displayed value does change and an onchange event is fired. The alternative is to use up/down without opening the list, in which case the displayed text changes with each key depression, and in this case the onchange event should happen, but doesn't in Gecko only (amongst software I know of [except that some Unix-based code doesn't react to the keyboard at all, which is entirely unacceptable, but I don't want to go there]). This last behaviour is what all this debate is about. Fixing the Web sites which abuse this control is irrelevant - their problem is their problem, and if they discourage their users by bad behaviour, only they should care. The bad thing is making behaviour wrong for all the other sites which don't abuse the control, and I have personally never run into a site which does use the thing as a navigation tool.
The only solution I can think of that does not involve timers is to make UP/DOWN actually open the menu, like comboboxes on Mac do. Since we need to implement that behaviour on Mac anyway my thought was to make it a hidden pref that people could use on other platforms as well. I still think we should fire onchange on UP/DOWN, by default, to be compatible with all other major UAs (see comment 83). It's unfortunate that the de-facto standard contradicts Web Forms 2. Is it to late to change WF2 to say that to get the new input/change behaviour you need to have a (possibly empty) 'oninput'?
(In reply to comment #125) > Brendan Eich: Sarcasm is not a good approach, nor using "duh"-type remarks. Look to your own words. You repeated the same pedantic reminder that Gecko is not the only browser rendering engine out there. We know this. Don't spam this bug with repetitive pedantry. > Fixing the Web sites which abuse this control is irrelevant - their problem is > their problem, and if they discourage their users by bad behaviour, only they > should care. The bad thing is making behaviour wrong for all the other sites > which don't abuse the control, and I have personally never run into a site > which does use the thing as a navigation tool. I know, that's why I keep supporting us changing to match other browsers, absent a new synthesis. But your attitude and logorrhea really make me wonder if I'm on the right "side" here.... /be
*** Bug 353968 has been marked as a duplicate of this bug. ***
I was reading theses posts and fuond it quite funny. I agree, the W3C standard is wrong, IE has it right, and FireFox needs to use update onchange when keyboard key is pressed. Personally, I just set the onkeydown event to be the same as onchange. Alot of you say people use dropdowns for navigation.. to that I say pah... they need to get with the times. And just to let you know, it's more common now to use AJAX changes with dropdown controls than it is redirects. And again, who selects where they are going to be redirected to with the keyboard? Browsing a selection with the keyboard implies you want to view each selection one at a time and see the changes. Using the mouse implies you want to view all the selections at one time, and choose from a broad list. The latter is what happens with a redirect box.. not what all these developers want to do, because if it was, it wouldn't be reported as a bug. Change this!
Say you have two combo boxes. The first one is enabled. The second is disabled. The first one has an onChange attribute that makes an XMLHttpRequest to dynamically populate the second combo box. Once the second combo box gets populated successfully, it becomes enabled. The current Firefox keyboard implementation of onChange (where the control must get blurred before any action takes place) in this example means that when you tab off of the first combo box, instead of focus going to the second combo box, focus immediately goes to the address bar, because the second combo box is still populating, and therefore has not become enabled (regardless of how fast the population and enabling happens -- even on a LAN where the result is visually instant, this behavior remains; tab still goes to the address bar). Not only is this a usability issue, but it is also an accessibility issue, because focus is taken off the page completely, leaving a blind or visually impaired user in the dark (no pun intended).
(The stance of the people who don't want to implement this is that you can press Enter on a drop-down box to trigger the onChange event without de-focusing it. Of course, that stance does not address your example of a blind or visually impaired user, who cannot see that there is a disabled drop-down box (no pun intended) and has no way of knowing that it would be wise to press Enter, or indeed that there is any XMLHttpRequest going on that dynamically changes the website.)
I am dismayed that, amongst this worthy debate, not one person has mentioned ADA standards*. People with certain disabilities may only be able to use a keyboard (or a device that simulates keyboard actions) to navigate the web. Java_script_Dude commented "For those who have issues with this, train users to hit enter key". Certain people, due to a handicap, may not be "trainable". In fact, after familiarizing oneself with ADA standards, it's likely many designers will agree that the only retraining required is that of the web programmer's methodology. ADA standards work quite well for non-handicapped persons too. Perhaps one remedy is for the W3C to create a new Event that is unique to (triggered by) a keyboard action only. Either way, like many others, I await an suitable resolve. *The ADA Standards for Accessible Design apply to new construction and alterations covered by the Americans with Disabilities Act (ADA). For more info, visit here: www.usdoj.gov/crt/ada/stdspdf.htm
(In reply to comment #3) > http://www.w3.org/TR/html401/interact/scripts.html#adef-onchange -- <q>The > onchange event occurs when a control loses the input focus and its value has > been modified since gaining focus.</q> > > Definately should be wontfix. If the developers truly wanted to implement the behavior like that, they got it wrong because expanding the list, changing selection, and pressing Enter calls onChange. So, current implementation conforms to neither the W3C recommendation nor users' expectations. My recommendation: drop the one-click-bookmarking nonsense and fix this problem. Otherwise, websites will have to have to be marked with "Optimized for Internet Explorer" :)
Just in case I wasn't clear: "expanding the list, changing selection, and pressing Enter" is done by keyboard, and the focus remains on the select element.
Pretty ironic that the "Download Day 2008" page has joined the ranks of those idiotic pages abusing select onchange for navigational purposes. Try to change the language with JS disabled: doesn't work; try to change the language with the keyboard in IE from English to Italian and you get the Spanish page. A great example that too many webmasters just don't learn and that's why Gecko should keep its current behaviour. Please restore the WONTFIX resolution and implement the oninput event.
This was first reported in 2002-02-19. In five days it will be siz and a half years this idiocy has been going on. The effectiveness of open source projects at work! Also a triumph of democracy, in its way. A couple of people who like using deviant navigation techniques stand in the way of millions of users. It seems worth stressing that this is an input device, and the behaviour as implemented is inconsistent with other browsers, other identical input devices in non-Web environments, and user expectations. It's time this was sorted out. That it is still reported and commented on regularly means it's not going to go away, and the Mozilla user base is getting frustrated.
Hm... Why is this bug still "NEW" and not marked "WONTFIX"? Most other significant problems with Mozilla products are marked "WONTFIX", and this one here is not being ignored any less than they.
The more that you guys spam this bug, the less inclined the devs are going to be in fixing it. They know the bug is here and when it is needed it'll be fixed, if you want it done sooner then learn to code and fix it yourself instead of complaining. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Ryan's comment is misleading. Don't waste your time trying to implement this. Your patch won't be accepted anyway.
/agree with Timwi It's not whether the "developers" won't fix it. Problem is the governing body won't approve it. Note to herceles: 1 year isnt bad, I've been waiting for this one bug reported in 1998 to get fixed.
With reference to Ryan Jones' comment: the comments added here are not spam, but new people finding the problem, and people trying to suggest ways to get around the problem. They also serve to indicate that the problem is one people keep trying to get around and that it rates attention - if nothing new was being said, it would be easy to assume that people had worked out solutions or come to terms with this deviant behaviour, which would in turn justify no action being taken. Brad: It's actually 6.5 years, but it is at least the current century's bug, unlike yours. Frankly, this issue undermines Firefox's credibility for me. New glitzy features keep getting added, but the basic functionality is still flawed, and I would rather, to use a motoring metaphor, have functional windscreen wipers than 5.1-channel sound on my navigator system. Considering this alongside with the bungling of session-handling in recent releases (yes, a separate issue, but is it worth reporting it as a problem?), I have changed from being an enthusiast to a seeker after a new browser, and one day I'll find the time to look.
(In reply to comment #142) > With reference to Ryan Jones' comment: the comments added here are not spam, > but new people finding the problem, and people trying to suggest ways to get > around the problem. Actually most of them are not. They violate rule 1.1 of the Bugzilla Etiquette. You guys are suggesting a patch won't be accepted when you haven't even tried to write and submit one. You can't expect others to fix what you aren't willing to fix yourself people.
> They violate rule 1.1 of the Bugzilla Etiquette. Which is a good indication that nobody knows this "Etiquette" page even exists, much less reads it. > You guys are suggesting a patch won't be accepted when you haven't even tried > to write and submit one. Correct. There are rejected patches from other people on BugZilla. I have no reason to believe that mine would be any different. > You can't expect others to fix what you aren't willing to fix yourself people. Perhaps, but you should still consider ideas from non-coders. Not everyone who makes sensible design suggestions can implement them by themselves, and not everyone who is a good coder makes sensible design decisions. See: http://mpt.net.nz/archive/2008/08/01/free-software-usability
In response to Ryan Jones: I've rather presumed that access to the primary code which constitutes the official release of Firefox is restricted to a bunch of developers who maintain and enhance it. Not just anybody is able to change it, surely? Hence people discuss the matter here. The source code can be downloaded, I believe, so I could generate my own, personal copy of Firefox which works correctly, but that would not help the users of my software unless I were to distribute my FireFoxFixed. The thing we don't want is a proliferation of Firefox versions, the way Linux is fragmented. We want the official release to work correctly, don't we?
@Hercules Gunter: Not really. You can write patches, if they get a review and a super review then you can seek to get them landed on a release build. It's a simple matter to download the code, write patched and submit diff files here for the developers to look at and comment on.
You might have better luck getting a patch for bug 312094 accepted. Bug 312094 - Add support for <select oninput>
I agree with Brendan Eich's comment (#123) about how it's often possible to both have our cake and eat it. In this case, I think the best way to do that is via a user preference to toggle between the two behaviours, with the default being to fire the event on each keypress that changes the value. One point that I think has not been made, is that pressing the Enter key to fire the event is absolutely not intuitive or learnable. The Enter key on most form elements actually submits the form, which is something you don't want to do lightly. Nobody will think that pressing Enter on a select element does something entirely different, and there's no way the interface will teach them. The current behaviour is only useful for those users who navigate exclusively by keyboard, and that only after they have learned the "Enter key" trick. The alternative behaviour (firing the event every time) is better for programmers (more consistency between browsers) and works better with dynamic forms, since it means that users never have to see an inconsistent state where the select box has been updated but not the other form elements. I think it's clear enough that this second behaviour is better in the vast majority of cases. And for anyone who needs to use the keyboard for navigation on BROKEN SITES, since they already have to learn the special usage of the Enter key, I don't think it's too onerous to ask them to install an extension or toggle a preference.
I'd like use scroll wheel when I active a option box. This behaviour is available in IE6. http://fpts.com.vn/user/chart/ When you use Mouse scroll in "Stock exchange", you can see the image changing. This is a nice performance of "onChange" But IF you use firefox, using scroll wheel is scoll page. So bad.
In response to comment 151 (Roger Espel Llima) Introducing a new unusual (and non-intuitive) behaviour, as you suggest, would make for a less consistent and predictable experience for the user, and not improve things at all for the developer. The problem is that the FireFox behaviour is deviant. Every other implementation of the combo box/dropdown list, in every other browser and in non-browser software, I have ever come across supports the following behaviours: - clicking with a mouse will open the list, allow scrolling and selecting of an item, and on selection the list closes and the on-change event fires; - Alt+Down will open the list, scrolling is possible with the up/down keys, typing a letter advances to the next item starting with that letter (occasionally, typing continuously will search for the next word starting with that sequence), and Enter will close the list and fire the on-change event; - up/down will move through the list, typing behaves as for an opened list, and each new selection fires the on-change event. If you've ever suffered from mouse-induced RSI/OOS/CTS (or whatever you prefer to call this painful condition), you use one of the non-mouse methods. Firefox differs in that in the last case, it does not fire the on-change event unless one then opens and closes the list, or moves the focus to another control. Supporters of this deviant behaviour argue that the RFC (Request for Comment) can be so interpreted. Given that all other implementations of this otherwise-standard control behave differently, the RFC statement must be in error. Perhaps the solution is to get the W3C to issue a corrected RFC? The argument for the present behaviour is that it would cause inconvenient results if this (input) control is used as a navigation tool. Therein lies the problem, though: it's not a navigation tool, but an input tool, and using it as a navigation tool is not a good idea, especially since visitors to such sites who use other browsers will suffer the annoyance (of disappearing to another location if they use the arrow keys), and that's still probably most visitors. But it seems that a small number of people who happen to be able to choke the fixing of this bug happen also to like perverting the dropdown list in this way, and so Firefox is a far less desirable browser than it would otherwise be - certainly, it's no longer my favourite. The fact that people keep rediscovering this deviant behaviour suggests strongly that the majority view is that it's an undesirable behaviour. I doubt that it will change unless an RFC describes the intended behaviour correctly, and even then I would not be hopeful. The problem with the present behaviour is that selecting a new value with the arrow keys does not, as with every other way of selecting a new value in this control, result in updating of other parts of the page should this be desirable. This means that the behaviour of the control is annoyingly inconsistent, and the user experience is significantly poorer when using richly-interactive applications with Firefox.
In response to #154: We're basically in agreement that the default behaviour should be to fire the event. We're giving the same reasons why this is good (dynamic forms stay consistent on-screen), and I'm also giving reasons why the opposite behaviour is not so good (the Enter key trick is not intuitive or easy to discover). For users who need to navigate using the keyboard alone, as you point out, they already have the possibility to open the drop-down box with Alt-Down, navigate it and press Enter. Now, if some people find it really important that one should be able to navigate such a box, without the events firing, using the arrows alone, well, I'm not going to deprive them of their convenience. I merely suggest moving this special-case behaviour to a user preference, because it's clearly not the best thing for the vast majority of users. Just having this option does not make the user experience "non-predictable", since you just get the default (and sensible) experience, unless you actually went and chose the other one. Think of it as just another accessibility option. It does not make life any harder for the developer either, because anyone who has explicitly configured their brower not to fire the event on keypresses can be expected to handle the resulting inconsistencies, and to know that you need to press Enter or tab away. They actually want it this way, so the developer does not need to do anything special about it. To summarize, the main point is that the event should fire by default. But if a small percentage of people really like using the arrows followed by Enter, rather than pressing Alt-Down first, there is no major problem with giving them that as a user-configurable option. It's truly a question of how the user prefers to interact with select boxes. The question now becomes: is there ANY REASON LEFT not to change the default behaviour? I think all the given reasons have been thoroughly refuted by now.
Response to #155: Roger, I understand what you're saying, but my point is that this is just one implementation of a standard control, used in many contexts (Web sites as well as thick-client software), and for that reason the behaviour should be predictable and consistent in all implementations - rather like the indicator control on a car, which should always rotate to the right to turn on the right indicator, rotate left for left, and never be implemented with forward/back motion. The difference in behaviour can only be at the client side, and the difference in what the control is used for can only be at the server side. Inflicting a difference on Firefox users at the client side makes the Firefox implementation unsatisfactory, and makes the browser's behaviour non-standard from the point of both users and developers. It's not just that the behaviour in Firefox is different from every other browser (IE, Opera, Safari, Chrome, Netscape before IE became dominant), but that it's different from every other implementation of the combo box I have ever come across in any other OS or development tool.
For consistency just within the (non-multiple) select element itself, when the current option is changed, either onchange should not fire (via mouse nor keyboard), or it should fire (via mouse or keyboard action). It seems clear to me the latter is preferred and what I was expecting. Not only would it make the onchange event work consistently for this one type of element, but it sounds like it would bring it in line with other browsers and more importantly, it's just logical. onchange, for an element should should trigger on change. Why have it fired just because a mouse movement changed the selected option, but not when a keyboard action changed it?? (If using the mouse, I am not losing focus, but just selection another option and the onchange fires. So forget about something losing or gaining control! And please don't cloud the situation by suggesting that people change their design to use blur or enter key - the goal should be to make this element work in a consistent, logical way.) I just wanted to change a total field that calculates times of day when the operator changes AM to PM or back. I was very surprised when testing that down arrow did not trigger the onchange. not good.
Very much agree with bruce above.
(In reply to comment #159) > Very much agree with bruce above. Also, to clarify a bit more: The onchange should be firing if the selected option has changed regardless of what caused it from the keyboard. So this would include, for instance keying a letter that matches an option that would result in that option becoming the new selected value (without ever using the mouse). So Brad was right way back in 2007 and then later (comment 136). I am really surprised that FF has lagged behind on this for so long. It seems onchange meant one thing long ago, then everyone wanted to get more dynamic and now everyone except FF has met these obvious needs. Except they didn't meet them now, they met them long ago. I am sure most of us have used a page where you have a series of selects where ajax or json scripts are used to tailor each subordinate select element's options based on the selection of the last (visit any tire merchant site, where you have several selects in a row for year, make and model). FF usually works, but stumbles through these (it is sometimes visually obvious) because it is not triggering onchange immediately as the selected options change. It appears as if it is trying to catch up as you open each subordinate select (gaining focus on a 'child' select right after losing focus on a 'parent' select). On some sites, keyboard alone is almost unusable for this scenario as various kinds of additional disabling/re-enabling trickery been applied to keep users out of trouble. This is not an issue of navigation - this is a matter of using a page in all its dynamic glory using the keyboard. Sad that the several year old IE is more logical and useful on this point.
(In reply to comment #160) > (In reply to comment #159) > > Very much agree with bruce above. > > Also, to clarify .... [snipped rest of my own reply] Seems this problem sloshed its way into Safari design as well. There, the behavior is even more inconsistent - patched in the wrong way. Using up/down arrows, now the select window is opened showing what currently is selected and the operator must hit enter to change the current selection. This would be acceptable if it were not inconsistent with what happens when using another keyboard key that matches an option value that causes the current selection to change (without losing focus of the select element); here again in this latter case, onchange is not firing. Ridiculous. How has this gone on for so long?
I didn't read the entire thread, but I think, as what some of the above posters do, that the keyboard selection should be consistent with the mouse selection. A direct change in the select box without a drop-down should be considered the same as an entire process of drop-down, selection/roll-up, and thus should trigger the onchange. If the user so wishes to change without triggering the onchange, he should press Alt-Down to get the select to drop-down and do the selection with the keyboard. This should not trigger the onchange until the selection is made. Also, I don't see why Firefox is inconsistent with the other browsers in another aspect. I might want to file a new bug for this: as the user is selecting in the *drop-down* with his mouse/keyboard, the value for the entire select control *changes* even though the onchange event has not fired!
I think I agree with Artjom (see my comment 54). It would be best if sites were careful about when to use oninput and when to use onchange, but in practice they're going to test with mouse or trackpad input and decide that onchange is what they want. See also bug 858917 for <input type=range>. We should probably try to get the spec changed too: http://www.w3.org/html/wg/drafts/html/master/forms.html#event-input-change "When the change event applies, if the element does not have an activation behavior defined but uses a user interface that involves an explicit commit action ..." http://www.w3.org/html/wg/drafts/html/master/forms.html#the-select-element "Upon this option element being picked (either through a click, or through unfocusing the element after changing its value, or through a menu command, or through any other mechanism) ..."
I think I've encountered this bug today while trying to enter the CC-details into GOG's payment-form: http://i.imgur.com/aRPe5ih.png If I read their code correctly, they're using jQuery's .trigger("change") in _min_checkout.js. I'm clicking into the "Card number"-line, and then switch the focus with the tab-key. No point in using the mouse there. When I want to change the month and year of the expiration date, I cannot see what value I've highlighted until I change focus to the next object with tab or a mouseclick. No such problem with IE9(!) and newer or Chrome 31.
I believe arrow keys should fire onchange events for dropdown lists. If they do not, then onchange is exactly like onblur. In that case, what's the point of having both? They both only fire when the focus changes. Logically, "on change" should occur when the VALUE changes not when FOCUS changes. I agree with comment #24 - in this case w3c got it wrong.
Duplicate of this bug: 969068
The expected behavior is a change of selection option triggers onchange. This currently occurs for a mouse user on the second click of the select box (one to open, one to select from the list...) but the focus does not change. If I managed to focus on the select box by tabbing and then used the mouse to select an option, my focus hasn't changed. By the currently accepted interpretation of Firefox, the onchange event shouldn't fire for a mouse user on that second click, but on loss of focus of that dropdown element. A mouse user should have to click on something else on the page or tab for that onchange event to fire. This inconsistency, namely that keyboard users are treated differently than mouse users, has lead to accessibility issues for many of us developers because we have to address an inconsistent treatment of users built into the browser. Mouse users have preferred treatment for selecting options currently, as their selection is treated as "real" while a keyboard user is treated as "incomplete" for what is essentially the same action. This appears to be applied unevenly, as the "loss of focus" argument is only used with regard to keyboard access, never to mouse access. If we had consistent treatment (either mouse users don't get onchange until loss of focus, or keyboard users get change events on change of selected options) it would help to address current issues we have with trying to develop a consistent experience for all of our users regardless of access type chosen for interaction. I would like to see this addressed cogently with consistent arguments, and would prefer the status be changed from "wontfix."
Just wanted to reiterate a workaround that I used that does work (for me) posted earlier by Simon Wunderlin. The patch can be found here: https://bugzilla.mozilla.org/show_bug.cgi?id=126379#c115 or https://bug126379.bmoattachments.org/attachment.cgi?id=235225 (direct). It's as easy as adding the js to the page and a size="1" attribute to each select control you want to apply the workaround to. Regardless of whether the browser should be changed or not, it is important to remember that not all users will have new browser versions so older versions must be supported, and this little hack works wonderful. Web devs, be sure to check it out. Shout out and thankyou to Simon Wunderlin for contributing the workaround.
worth noting that in the latest Firefox (Quantum-based) this now seems to have finally been resolved. At least from my testing, onchange is fired consistently with how other browsers do it. x-ref https://github.com/w3c/html/issues/263#issuecomment-345838693
You need to log in before you can comment on or make changes to this bug.