Skip to main content

Search and Top Navigation

#8750 closed bug (notabug)

Opened October 30, 2012 08:14PM UTC

Closed October 31, 2012 12:49AM UTC

Last modified December 12, 2012 11:55AM UTC

Spinner misses click events in IE8

Reported by: dsargent@gmail.com Owned by: dsargent@gmail.com
Priority: minor Milestone: 1.10.0
Component: ui.spinner Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:
Description

In IE8 (or IE9 in IE8 mode) the spinner widget does not capture all of the click events on the up and down arrows unless the user clicks them VERY slowly. On average it misses every one other an "normal" speed.

http://jsfiddle.net/bxrgK/

Much to my dismay and full half of our users are still using IE8 </sad>

Attachments (0)
Change History (8)

Changed October 30, 2012 08:30PM UTC by scottgonzalez comment:1

owner: → dsargent@gmail.com
status: newpending

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?

Changed October 30, 2012 11:46PM UTC by dsargent@gmail.com comment:2

status: pendingnew

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.

Changed October 31, 2012 12:07AM UTC by scottgonzalez comment:3

status: newpending

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?

Changed October 31, 2012 12:17AM UTC by dsargent@gmail.com comment:4

status: pendingnew

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.

Changed October 31, 2012 12:49AM UTC by scottgonzalez comment:5

resolution: → notabug
status: newclosed

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.

Changed October 31, 2012 10:27PM UTC by dsargent@gmail.com comment:6

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.

Changed December 11, 2012 03:06PM UTC by fedot comment:7

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.

Changed December 12, 2012 11:55AM UTC by fedot comment:8

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.