Bug Tracker

Modify

Ticket #11808 (closed bug: worksforme)

Opened 12 months ago

Last modified 11 months ago

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

Reported by: chris.wilhelm@… Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.2
Keywords: Cc:
Blocking: Blocked by:

Description

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.

Notably: 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:  http://jsfiddle.net/mjbmZ/11/ 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:  http://stackoverflow.com/questions/1402698/binding-arrow-keys-in-js-jquery

Change History

comment:1 Changed 12 months ago by chris.wilhelm@…

comment:2 Changed 12 months ago by dmethvin

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  http://jsfiddle.net/mjbmZ/12/ 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.

 http://youtu.be/wNJZpm7yZ3E

Can you provide some more information?

comment:3 Changed 11 months ago by dmethvin

  • Status changed from new to closed
  • Resolution set to worksforme

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.