Spinner misses click events in IE8

I'm not seeing this. What do you mean by "clicks them VERY slowly" Do you mean a long delay between down and up or long delays between clicks?

I'd say about 300ms or so. If you click the up arrow fast than that IE8 will skip about half the clicks on average. So if I click the up arrow 20 times the number would end up 10, not 20. In IE9, Firefox or Chrome it all tracks one to one.

If you create a button that logs out clicks and you click that fast are you seeing the same behavior or are you getting all 20 clicks logged?

Ohh, great call, didn't think of trying that.

Same results with a simple click event on a button (using jQuery). That is so strange.

http://jsfiddle.net/BadSA/

I'm at home now (I was at work before), so am on a different computer with the same results. In this case it's Windows 8, IE10 in IE 8 mode (F12, Browser Mode IE8, Document Mode IE8 Standards).

I had a coworker test the first jsFiddle in IE8 proper with the same results. Is this an IE8 issue then, or maybe a jQuery issue? I haven't tried doing it in plain vanilla JavaScript.

Probably IE8, but it certainly doesn't seem like anything we should try to work around in UI. It doesn't even really sound like a bug on spinner.

I agree. I did a "bare metal" test

http://jsfiddle.net/VZrQe/

and found it does it with plain javascript and no libraries loaded.

Kind of mind blowing how slow IE's JS engine is.

This problem has nothing to do with the "slowliness of IE's JS engine".

The issue is in how (badly) IE handles the double-click event.

If you click the same spinner button more than once within a few hundred milliseconds, IE (and any other browser) starts treating this situation as a double-click event. This is not a problem in itself since all ''normal'' browsers fire their events correctly. This is what ''normal'' browsers fire during a 2-click sequence that is treated as a double click event:

mousedown, mouseup, click, mousedown, mouseup, click, dblclick

However, IE 7/8 (probably others too) fire the following events instead:

mousedown, mouseup, click, mouseup, dblclick

Here is a jQuery code to prove the above:

$(function(){
  $('body').on('click mousedown mouseup dblclick', function(e){$(this).append(e.type+'<br />')});
});

You can clearly see that a spinner widget will have problem there.

Spinning is bound to a mousedown event and the 2nd mousedown is 'swallowed' by IE (together with a 2nd 'click' event). 2nd mousedown just never fires in IE7/8 during double-click events sequence. This is why you get only half of your spin events (as described above in the original bug report).

One possible workaround could be to bind mouseup event instead of mousedown. However, I am not 100% sure if this will play nicely with pressing and holding the up/down buttons (when you want the spinner to spin for a while). Perhaps pressing/holding and simply clicking can be "separated" into mousedown / mouseup events.

However, I believe the problem is more generic here. I think IE7/8 behaviour (did not test other versions) is broken and should really be normalised in jQuery event/core. If jQuery core did fire those missing events for the affected IE versions no workarounds or fixes for this issue would be needed in jQuery UI (or any other application relying on jQuery).

Perhaps somebody from jQuery UI team has ability to bring this to jQuery event/core developers' attention.

In addition to the previous message, I have managed to fix IE's "spinner double-click behaviour" with the following piece of code:

if ($.browser.msie){
  var ieVer = parseInt($.browser.version, 10);
  if (ieVer == 7 || ieVer == 8) {
    $(document).on('dblclick', '.ui-spinner a', function(e){
      $(e.target).trigger('mousedown').trigger('mouseup');
    });
  }
}

Disclaimer/Rant/IMHO:

Yes, I know the usual "''I should not be using jQuery.browser as it has been deprecated, will be moved to a plugin, etc.''", however, this is exactly where the 'feature detection' (which is suggested instead) is not going to help.

Incidentally, the comments on the jQuery's $.browser and $.support documentation pages are full of similar "rants". When dealing with well known browser bugs there is no other way but to know which browser and which version of a browser your code is running in. And yes, I am also aware that the UA string can be easily spoofed but it is still better than nothing (and those who spoof UA strings should be ready to face the consequences anyway).

IMHO, it is rather short-sighted to remove $.browser from the jQuery core while IE7/8 are still alive and kicking. There are valid use cases for both $.browser and $.support and one does not truly replace the other (and that is true both ways). Instead of removing $.browser, developers should be better educated when they should be using $.browser and when they should not.