Closed
Bug 249122
Opened 20 years ago
Closed 20 years ago
select control's onchange event does not fire when using down- or up-arrow keys
Categories
(Core :: DOM: Events, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: gpm2a, Unassigned)
References
()
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1 If a <select> control has a size= attribute > 1, the JavaScript onchange event fires not only when the user changes the selection by using the mouse, but also when using the down-arrow or up-arrow keys on the keyboard. This seems appropriate. But if a <select> control has a size= attribute of 1 (or no size attribute, since 1 is the default), the behavior of the onchange event is different. In this circumstance, the onchange event does not fire when changing the selection using the keyboard. Instead, it changes after the select control loses focus. Reproducible: Always Steps to Reproduce: 1. Go to the above URL 2. The select control with size=4 has a JavaScript onchange event handler that fires whenever the selection changes, whether by mouse or keyboard 3. The select control with no size attribute (thus having size of 1) also has a JavaScript onchange event handler, but it fires only after the select control loses focus Actual Results: The onchange event fired, but only after the select control lost focus. Expected Results: The onchange event should have fired each time the selection changed in the select control, whether changing the selectino by keyboard or by mouse. This behavior also occurs consistently using Mozilla 1.7 and a nightly build I just downloaded: build ID 2004062908
See http://www.w3.org/TR/html401/interact/scripts.html#adef-onchange
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
I see from your link to the W3C recommendation for HTML 4.01 that the definition of the onchange event refers to the control losing focus, as well as having a new value. So clearly the current behavior of Mozilla is technically correct (although by this definition its behavior is technically INcorrect if the select control has a size > 1). But I would encourage you to see "the spirit, not the letter" of the recommendation. The reference to losing focus is in the context of other controls, not just the select control: -quote- The onchange event occurs when a control loses the input focus and its value has been modified since gaining focus. This attribute applies to the following elements: INPUT, SELECT, and TEXTAREA. -end quote- For input and textarea controls it makes sense to wait until the control loses focus to consider the value to be changed. But for a select control, common sense suggests that the value of the control changes when the selection changes, not when the control loses focus. My real point here is that Mozilla fires the onchange event when the selection changes IN ALL CASES EXCEPT when the control is changed via keyboard (rather than mouse) and when the size of the control is 1. This inconsistency is what makes this issue a bug, not a feature.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 3•20 years ago
|
||
We do this on purpose so people who do stuff like <select onchange="document.location=whatever"> (about 99% of onchange handlers for selects look like this) don't make it impossible to navigate the select via keyboard. We've had bugs filed on the matter before, as a simple search on "select onchange" shows...
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•