Skip to main content

Bug Tracker

Side navigation

#14186 closed bug (patchwelcome)

Opened July 26, 2013 07:24AM UTC

Closed July 26, 2013 03:51PM UTC

Last modified July 26, 2013 04:04PM UTC

jQuery change is not fired for select when using key strokes

Reported by: SuperNova Owned by:
Priority: low Milestone: None
Component: event Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:


when binding the change event to a select with a size of 1 (default), the change event is not fired when using key strokes to select an element.

This can be tested on this site:

The multiple="multiple" attribute must be removed from the select in this test case (I did this using firebug).

Steps to reproduce: Focus the select and use up/down keys to navigate through the select. The text under the select is not changed anymore. When using mouse/drop down, all is fine.

Tested with Firefox 22.0

Attachments (0)
Change History (8)

Changed July 26, 2013 01:59PM UTC by dmethvin comment:1

resolution: → notabug
status: newclosed

This is consistent across all browsers:

Press Enter to select the option.

Changed July 26, 2013 02:47PM UTC by SuperNova comment:2

It is not consistent to all browsers:

Firefox: Enter must be pressed

Chrome: The event is fired immedietly

Opera: The event is fired immedietly

Internet Explorer 10: The event is fired immedietly

Safari: Enter must be pressed

Newest windows versions of every browser. I think a library like jQuery should be the one which provides equality in all browsers when using javascript. This is one of the main reasons, why I'm using jQuery.

Yes, it would be possible to create a workaround every time I'm using the change event. But, no I don't want, because I think the library should do this. It might by a browser bug, but jQuery currently fixes so many browser differences. This is another one.

Changed July 26, 2013 03:16PM UTC by dmethvin comment:3

I am not seeing a difference. If I focus the select and move up and down the list with the arrow keys, I do not see the change event occur in any browser.

Changed July 26, 2013 03:23PM UTC by SuperNova comment:4

The changes in chrome (for windows), opera (for windows) and internet explorer are fired each time the selection is changed via key down/up (without pressing any other key or using the mouse). I used your fiddle with chrome 28.0.1500.72 m, opera 12.15 and internet explorer 10.0.9200.16635.

Changed July 26, 2013 03:50PM UTC by dmethvin comment:5

resolution: notabug
status: closedreopened

I was opening the select with the mouse before using the keyboard. It doesn't happen then. The select control behaves differently depending on whether the dropdown is open or not. Here's a gifcam of Chrome for example:

If the dropdown is closed, the keystrokes fire a change event. If it is open, the keystrokes simply change the focus on the open dropdown and do not fire a change.

If the select is a single select and the size is greater than 1, the behavior again differs and it looks like Firefox does fire change on a keyboard navigation:

So, when the same keystrokes have different effect and there is no script indication of the "mode" the select is in, the only way I could see to solve this inside jQuery would be to listen for a change event and then fake one if we don't "see" one. That is not generally a reliable approach but I will mark this as a patchwelcome if someone would like to try it or some better way.

Changed July 26, 2013 03:51PM UTC by dmethvin comment:6

component: unfiledevent
priority: undecidedlow
resolution: → patchwelcome
status: reopenedclosed

Changed July 26, 2013 04:02PM UTC by SuperNova comment:7

Thanks for clarification. The closed drop down with keyboard navigation is a use case, when tabbing through the controls of a form. So the drop down is never opened. I don't know why firefox and opera are not firing a change event when using the keyboard.

Changed July 26, 2013 04:04PM UTC by dmethvin comment:8

If you want this fixed at the browser level, please file bugs on the Firefox and Chrome trackers and post a link here. We'll be glad to weigh in on them.