arrow keys should not fire onchange (drop-down listbox)

VERIFIED FIXED in mozilla0.9.9



18 years ago
17 years ago


(Reporter: jruderman, Assigned: john)


({access, regression})

access, regression
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments)



18 years ago
Many web developers seem to think the semantics of onchange for a <select> 
element is "when the user makes a selection" rather than "when the user changes 
the value shown in the select", and I think that's a reasonable assumption.

Steps to reproduce:
1. Find a page that uses a drop-down <select> element (with javascript) for 
navigation.  For example,
2. Focus the <select> using the keyboard.
3. Hit the down arrow key.

Result: you're suddenly taken to the second page on the <select>'s list.
Expected: you should be able to choose which page you want to go to, then hit 
tab or enter to fire onchange.

Note that fixing this bug might make forms containing <select>s more confusing, 
if modifying the value of a <select> changes other parts of the form.  I don't 
think that's as common as navigation <select>s.

This bug might have been fixed before in bug 42301.
jkeiser?  thoughts?
OS: Windows 98 → All
Hardware: PC → All

Comment 2

18 years ago
The reasoning makes sense to me, although it seems like this will depend on
other browsers' behavior.  I can't get NS4 to load the page, what does IE do?

Comment 3

18 years ago
IE and Opera both fire onchange as soon as you hit an arrow key.  I can't get 
onchange to work for <select>s in Netscape 4.
Keywords: access

Comment 4

18 years ago
Never mind, I was using a half-crashed Netscape 4.  Netscape 4 also fires 
onselect right away.

Comment 5

18 years ago
Created attachment 58494 [details]

Comment 6

18 years ago
I think the behavior is correct at the moment, especially because it matches 
IE, Opera and Nav 4.x.

But their is a regression from 6.2. Whenever an arrow key is pressed an onchange 

Here is the fix:
Index: nsListControlFrame.cpp
RCS file: /cvsroot/mozilla/layout/html/forms/src/nsListControlFrame.cpp,v
retrieving revision 1.227
diff -u -r1.227 nsListControlFrame.cpp
--- nsListControlFrame.cpp      2001/11/14 13:39:59     1.227
+++ nsListControlFrame.cpp      2001/11/20 16:44:16
@@ -3220,7 +3220,7 @@
     PerformSelection(newIndex, isShift, PR_FALSE);
     // Dispatch event
     if (mComboboxFrame && mIsAllFramesHere) {
-      mComboboxFrame->UpdateSelection(PR_TRUE, PR_TRUE, newIndex);
+      mComboboxFrame->UpdateSelection(PR_TRUE, PR_FALSE, newIndex);
     } else {
Keywords: regression

Comment 7

18 years ago
sr=attinasi for patch inline at

Comment 8

18 years ago

Comment 9

17 years ago
-> John, can you do me a favor and check in rods' fix when the tree reopens?
Assignee: aaronl → jgaunt


17 years ago
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8


17 years ago
Whiteboard: fix in hand, waiting for tree opening
checked in yesterday
Last Resolved: 17 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand, waiting for tree opening
arrow key just display the select list's items now. vrfy'd fixed using
2002.01.07.0x comm bits on linux rh7.2, winnt and mac 10.1.2.

however, i know that alt+down will drop down the select list --but i'm curious
why the first time i hit with just the down arrow doesn't drop down the list? is
that covered by another bug? thx.

Comment 12

17 years ago
Still broken in 2002 012008: pressing arrow keys at causes the newly selected 
item to load immediately.  Reopening.

Sairuh: on Windows, it's normal for up/down to change the selection without 
making the entire list appear...
Resolution: FIXED → ---
hmmm.... just tried this with a build from the tip: ( today's pull around noon )

works just fine. I can press up/down in the select without loading the next page
and I can use alt-up/alt-down to select without going to the next page. Only
once I hit enter does it take me on to the next page.
tried again, I was looking at the wrong type of widget. 

there is an input tag on the page linked to which is what I was testing against. 

So I tested the attachment and tested the select on the linked page. Both of
these cases where there was an onchange handler defined we process the onchange
as soon as the down arrow/ up arrow is pressed ( or if you are fast you can
scroll 2-3 items ).

changing the summary to represent the actual discussion in the bug.
Summary: arrow keys should not fire onchange for <select size=1> → arrow keys should not fire onchange


17 years ago
Severity: normal → major

Comment 15

17 years ago
This is fixed in the upcoming patch to 112241 (currently in review)
Depends on: 112241

Comment 16

17 years ago
Ooops.  Not fixed.  In fact, it's fixed /back/ to 4xp in the new bug.

We *cannot* just get rid of the onChange without doing something else.  The
problem is, the user can change the value, click on some other control, and
onChange will never be fired.  So if we are going to fix it to not constantly
fire (and I think this is good) we need to *also* make sure it fires when the
control loses focus.

We should not put in any fixes that do this halfway.  It's
data-integrity-destroying dangerous.
No longer depends on: 112241
seems to me the arrow keys should cycle through the list and when you get to the
one you want you press enter (or space). Just like when you drop the list down.

Currently, if you alt-down cycle to a new option and then alt-up, onchange is
_not_ fired, but if you alt-down cycle to a new option then hit enter an
onchange _is_ fired

ccing aaronl for input on behavior

Comment 18

17 years ago
jgaunt: we're both talking about the drop-down listbox, right?  That's what I 
meant by <select size=1> in the summary.

I agree that enter should fire onchange for a drop-down listbox if its value 
was just changed using the arrow keys.  If enter also causes the form to be 
submitted, onchange should fire before onsubmit.
Summary: arrow keys should not fire onchange → arrow keys should not fire onchange (drop-down listbox)
re-assigning to jkeiser since he just rewrote a bunch of this stuff and has a
better handle on the situation.
Assignee: jgaunt → jkeiser

Comment 20

17 years ago
I am fine with enter or space causing onChange to fire (if the box value has
changed), in fact I think that's a good idea.  But if we do that, tabbing out of
the dropdown or clicking somewhere else *also* needs to fire onChange.  We can't
just assume the user is going to be good and hit enter for us.  If we implement
this half-assed, data entry and query pages will get broken when people do this.
 At least this way data integrity is ensured, even if it's not perfect for
navigational pages.

So in short, we need to do all (no onChange on up/down, onChange on enter or
lost focus) or nothing (the way it is).  A third possibility is to have up and
down drop the combobox down.  That would fix it for everybody.
Target Milestone: mozilla0.9.8 → Future

Comment 21

17 years ago
I broke down and implemented this when bug 97543 showed up on my list.  Patch
Depends on: 97543
Target Milestone: Future → mozilla0.9.9

Comment 22

17 years ago
Created attachment 67780 [details] [diff] [review]

This fixes this problem by (a) not firing onChange for comboboxes, (b) firing
onChange onBlur iff the selected index has changed since onFocus or since
onChange was last fired.

Also adds more comments and makes it list/combobox incrementally more readable.


17 years ago
No longer depends on: 97543

Comment 23

17 years ago
Oops, hit enter mid-change, sorry for spam
Blocks: 97543

Comment 24

17 years ago


17 years ago
Blocks: 100188


17 years ago
Blocks: 107612
Marking nsbeta1+
Keywords: nsbeta1+
*** Bug 97543 has been marked as a duplicate of this bug. ***
*** Bug 107612 has been marked as a duplicate of this bug. ***

Comment 28

17 years ago
Comment on attachment 67780 [details] [diff] [review]
Attachment #67780 - Flags: superreview+
Attachment #67780 - Flags: review+

Comment 29

17 years ago
Fix checked in.
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
tested using 2002.02.11 comm bits on linux rh7.2, win2k and mac 10.1.2. this is
what i see:

a. up/down arrows select items in the listbox, but do not activate 'em.
b. however, after using the the arrows, if i hit tab to get out of the listbox
and go to the next link on the page, the selection is activated instead!

should i reopen this because of latter issue (b)? or file another bug [unless
it's already known]? thx!

Comment 31

17 years ago
If you change the listbox and then try to leave the listbox, onChange is going
to be fired, yes.  That is deliberate.  onChange *will* be fired whenever the
dropdown is changed.  Making an exception to this for navigation would cause
dataloss on applications that use onChange for validation.  That is not acceptable.

Now, if you hit ESC or change the listbox back to the value it originally was
before you tab out, onChange won't be fired.
ah, good to know! marking vrfy'd, then.

Comment 33

17 years ago
Filed bug 150759, "Enter should fire onchange for drop-down listbox changed with
arrow keys".  I mentioned that it should in comment 0 but didn't test it when
this bug was marked as fixed.  D'oh!

Comment 34

17 years ago
Several people have filed bugs about this change: bug 126379, "Select onChange
not called using down arrow key".
You need to log in before you can comment on or make changes to this bug.