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)

x86
Windows 2000
defect
Not set
minor

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 → ---
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 ago20 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.