Closed
Bug 110800
Opened 23 years ago
Closed 23 years ago
arrow keys should not fire onchange (drop-down listbox)
Categories
(Core :: DOM: UI Events & Focus Handling, defect, P2)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
FIXED
mozilla0.9.9
People
(Reporter: jruderman, Assigned: john)
References
()
Details
(Keywords: access, regression)
Attachments
(2 files)
257 bytes,
text/html
|
Details | |
11.14 KB,
patch
|
kinmoz
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
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, http://www.idocs.com/tags/forms/_SELECT_onChange.html. 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.
Assignee | ||
Comment 2•23 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?
Reporter | ||
Comment 3•23 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
Reporter | ||
Comment 4•23 years ago
|
||
Never mind, I was using a half-crashed Netscape 4. Netscape 4 also fires onselect right away.
Reporter | ||
Comment 5•23 years ago
|
||
Comment 6•23 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 fires. 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 { UpdateSelection(); }
Keywords: regression
Comment 7•23 years ago
|
||
sr=attinasi for patch inline at http://bugzilla.mozilla.org/show_bug.cgi?id=110800#c6
Comment 8•23 years ago
|
||
r=dcone
Comment 9•23 years ago
|
||
-> John, can you do me a favor and check in rods' fix when the tree reopens?
Assignee: aaronl → jgaunt
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8
Updated•23 years ago
|
Whiteboard: fix in hand, waiting for tree opening
Comment 10•23 years ago
|
||
checked in yesterday
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: fix in hand, waiting for tree opening
Comment 11•23 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 12•23 years ago
|
||
Still broken in 2002 012008: pressing arrow keys at http://www.idocs.com/tags/forms/_SELECT_onChange.html 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...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
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
Updated•23 years ago
|
Severity: normal → major
Assignee | ||
Comment 15•23 years ago
|
||
This is fixed in the upcoming patch to 112241 (currently in review)
Depends on: 112241
Assignee | ||
Comment 16•23 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
Comment 17•23 years ago
|
||
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
Reporter | ||
Comment 18•23 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)
Comment 19•23 years ago
|
||
re-assigning to jkeiser since he just rewrote a bunch of this stuff and has a better handle on the situation.
Assignee: jgaunt → jkeiser
Status: REOPENED → NEW
Assignee | ||
Comment 20•23 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
Assignee | ||
Comment 21•23 years ago
|
||
I broke down and implemented this when bug 97543 showed up on my list. Patch forthcoming.
Assignee | ||
Comment 22•23 years ago
|
||
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.
Comment 24•23 years ago
|
||
r=rods
Comment 26•23 years ago
|
||
*** Bug 97543 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
*** Bug 107612 has been marked as a duplicate of this bug. ***
Comment 28•23 years ago
|
||
Comment on attachment 67780 [details] [diff] [review] Patch sr=kin@netscape.com
Attachment #67780 -
Flags: superreview+
Attachment #67780 -
Flags: review+
Assignee | ||
Comment 29•23 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 30•23 years ago
|
||
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!
Assignee | ||
Comment 31•23 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.
Reporter | ||
Comment 33•22 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!
Reporter | ||
Comment 34•22 years ago
|
||
Several people have filed bugs about this change: bug 126379, "Select onChange not called using down arrow key".
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•