Skip to main content

Bug Tracker

Side navigation

#11808 closed bug (worksforme)

Opened May 23, 2012 10:37PM UTC

Closed June 12, 2012 01:11PM UTC

Browser discrepencies for .mouseup, .click, and .change when attached to <select> elements

Reported by: Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:

I had a setup with a <select multiple="multiple">, and several buttons that performed different functions on currently-selected options. Whenever the selection changed I needed to be aware of it so that the state of the buttons could be re-evaluated to restrict certain functions to certain options.

I used .change() initially, which worked properly in all browsers except MSIE<v9. Selections made with the keyboard (modifier keys and/or arrow keys) failed to trigger the event, as did certain sequences of clicks.

Using elem.attachEvent('onchange', callback) for older versions of MSIE completely resolved these issues.

Before I discovered that, I opted to try a combination of .keyup(), .mouseup() and .click() handlers to catch all the events normally seen by .change(). When selecting options in a list, the behavior on the latter two was different in MSIE than current versions of all other major browsers.


In MSIE through v9 at least, .mouseup() seems to be triggered BEFORE IE updates the .selected properties of the option DOM objects. Since my callback function detects selected options as its very first step, this proved to be an issue because it would effectively report the previous selection as the current one. All other browsers report the current selection visible to the user.

To resolve this I attempted to use .click() instead, which DOES report the current selection in MSIE through v9. HOWEVER, in all other major browsers, .click() is not fired if you make a selection of multiple options with a single click (mousedown -> drag -> release mouse).

I have a functioning jsfiddle demonstrating these issues:

Function getCurrent builds an array of what the browser sees as currently-selected, and reports that list with the name of the event listener type that triggered it.

For further discussion, please see my post on stackoverflow:

Attachments (0)
Change History (3)

Changed May 23, 2012 10:42PM UTC by comment:1

Changed May 24, 2012 01:52AM UTC by dmethvin comment:2

So to summarize one of the problems you described in the SO thread:

  • On IE8,
  • if there is no native onchange attached by .attachEvent(),
  • and you drag-select multiple elements,
  • jQuery's .change() handler isn't fired.

I cannot reproduce this problem using which is simply your test case with the .attachEvent removed. Here is a demo where I drag-select all three items on the list and it seems to fire the change handler. Then I click the last item.

Can you provide some more information?

Changed June 12, 2012 01:11PM UTC by dmethvin comment:3

resolution: → worksforme
status: newclosed