969068 - Arrow Keys should fire an onChange event on dropdown lists

Status: RESOLVED DUPLICATE of bug 126379

(Core :: DOM: Core & HTML, defect)

Description

[jbalyo]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140127194636

Steps to reproduce:

Create a simple HTML page with a dropdown list that has an onchange event that fires a javascript function.


Actual results:

When you select the dropdown list and use the arrow keys to cycle through the listed options, the onchange event does not fire. Only the Enter key or Tab key causes the onchange event to fire.


Expected results:

The onchange event should fire when the selected option is altered, even if it is by arrow key input. This makes sense programmatically and is the way that every other browser behaves. I can see that there has been a bit of a bug war over this issue, going back and forth. But I believe the wrong side eventually got their way. Is there a reason why Firefox has made a different decision on this issue than every other browser?

110800 - Someone requesting that the arrow keys should not fire onchange events
30463 - Someone requesting that arrow keys should fire onchange events

Comment 1

[Alice0775 White]

A minimal testcase uploaded using "Add an attachment" would be great.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> The onchange event should fire when the selected option is altered

The spec and accesibility considerations disagree with you.  A keyboard-only user should be able to select a new value without onchange firing on all intermediate values.

> Is there a reason why Firefox has made a different decision on this issue than every
> other browser?

Because we're apparently the only ones who care whether keyboard-only users can use the web.

In any case, here's the relevant spec bit:

  If the multiple attribute is absent, and the element is not disabled, then the user
  agent should allow the user to pick an option element in its list of options that is
  itself not disabled. 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), and before the relevant user interaction event is queued
  (e.g. before the click event), the user agent must set the selectedness of the picked 
  option element to true, set its dirtiness to true, and then send select update
  notifications.

note the "unfocusing the element" bit.

This is also how other form controls work.  If you type in an input, you don't get an onchange until you blur it.

Of course all this has been discussed at length before....

Comment 3

[jbalyo]

Boris - 

Similar to some other posts I've been reading on the subject, I would tend to disagree with w3c specs on this one. If both onchange and onblur fire on blur, then what is the point of having both? How, with these specs, can someone develop ajax lookups? For example, if you write a date lookup where you select the month from one drop down list and then the list of days adjusts its contents based on the month selection. If the person is a keyboard-only user, when they press tab to navigate to the Day dropdown box, the onchange would only then fire, making the ajax fire and changing the focus (since for a split second the Day element is vacant while it is being calculated).

For other browsers, you can set your ajax to fire onchange and then the Day select dropdown will be all ready to go by the time the user presses tab. As far as accessibility goes, w3c hasn't seemed to consider dynamically filled selections, because this standard actually makes such sites LESS accessible. I know, it's the programmer's fault for not bothering to work around these standards, but in reality, this is how many websites are built; in large part because most other browsers behave that way, so adhering strictly to the w3c standards on this issue seems a bit idealistic and detrimental.

Anyways, I know you won't change your mind on my account, but I saw this as a bug which actually hinders accessibility rather than helps it.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> what is the point of having both?

Onchange fires in cases other than onblur.

Onchange doesn't fire if the value hasn't changed.

Why are the issues you raise not issues for <input type="text">?

Comment 5

[jbalyo]

Largely because text inputs have onkeydown or onkeyup. These can be used to fire ajax calls while the user is typing, as the text is "changing". To do the same with a selection dropdown, you would have to read the input event keycode to determine whether or not it is a key that would change the active option. It's possible but not very ideal. Developers are bound to miss a keystroke or two that they didn't think of - especially when considering international accessibility.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hmm.  Seems like the right thing to do would be to fire "input" events when what the user has selected changes (just like we fire "input" events when the text in a text control changes) and fire "change" when the change is committed...

Comment 7

[jbalyo]

What we really need is a new javascript event - onScroll or something. Of course that's another world. When we're stuck with a limited number of events, it's helpful if they all have the same timing across the board. I guess that's the cost of working with client side code.