Select in Dialog causes slowness on IE8

[burgernofries]

When a select element with many option elements (approx 300 options) is clicked on or changed in a dialog, the mousedown event that is triggered on the dialog causes slowness in IE8.

Using jQuery 1.4.3, and jQuery-ui 1.8.6.

[theoradu]

I have the same issue with a table that has sortable rows. In one of the rows there is a select with 250+ options in it. It works fine in Chrome, Firefox, Opera and Safari, but it's very slow in IE (it takes about 4 seconds to open the select box and sometimes it's not being opened at all, it just promts you to stop all the scripts from running).

The code brakes only if you use jQuery 1.4.3+ and by using IE dev tools I've noticed that the problem is the siblingCheck function that is being called from within the sortOrder function. The sortOrder function has been entirely rebuilt in jQuery 1.4.3, so I'm guessing this function is not being called properly from within the ui.sortable component script.

P.S.: I'm using jQuery UI 1.8.6 but the same thing happens with older versions...

Edit: I've realized what this 2 issues have in common... ui.dialog and ui.sortable both use ui.draggable. So my guess is that you have to set the option draggable to false to get around this bug...

[burgernofries]

One workaround I've found is to bind a mousedown event to the select element that returns false so that it doesn't bubble to the dialog:

$('#selectElement').bind('mousedown', false);

[theoradu]

Replying to burgernofries:

One workaround I've found is to bind a mousedown event to the select element that returns false so that it doesn't bubble to the dialog:

$('#selectElement').bind('mousedown', false);

Thanks, that works.

[Scott González]

Replying to theoradu:

Edit: I've realized what this 2 issues have in common... ui.dialog and ui.sortable both use ui.draggable. So my guess is that you have to set the option draggable to false to get around this bug...

Good catch, the problem is definitely in the interaction plugins. Disabling the draggable option makes the select open faster. If you also disable the resizable option, the select opens immediately.

[rokclimb15]

I have produced a very minimal test case for this problem using jQuery UI 1.8.9 and jQuery 1.4.4, although the problem is also present in jQuery 1.4.3.

The _mouseDown function of ui.mouse.js appears to be responsible for the cascaded calls to add, although it seems add has become much less efficient in jQuery 1.4.3 and higher for IE browsers. Not sure if this is really a UI problem necessarily.

[rokclimb15]

I think the following change in Sizzle was responsible for the regression in performance under IE.

​https://github.com/jeresig/sizzle/commit/bb0828d44b6c9d360e6077187e1607076b6e67ab

[jebber007]

I have a similar issue, but it doesn't seem to be related to IE. I've found that some mousedown event is severely slowing down my select boxes. As soon as I put in a:

$(document).bind('mousedown', function(e) { e.stopPropagation(); return false; });

the problem disappeared, but caused other issues. I've tracked it down to JQueryUI, but not sure which binding to the document object is causing it. Can anyone else confirm this? or have a workaround other than my code above?

[jebber007]

Here's another interesting tidbit: If you remove the ui-widget class from the dialog, suddenly everything is screamin' again.

[omega2k]

Replying to rokclimb15:

I have produced a very minimal test case for this problem using jQuery UI 1.8.9 and jQuery 1.4.4, although the problem is also present in jQuery 1.4.3.

The _mouseDown function of ui.mouse.js appears to be responsible for the cascaded calls to add, although it seems add has become much less efficient in jQuery 1.4.3 and higher for IE browsers. Not sure if this is really a UI problem necessarily.

Hi @all,

I think I figured out your problem! It's the fault of "ui.mouse" on line 58

elIsCancel = (typeof this.options.cancel == "string" ? $(event.target).parents().add(event.target).filter(this.options.cancel).length : false);

Why is the check for mousedown on the close icon done in that way? The .add(event.target) method is the problem! I replaced this part by:

elIsCancel = (typeof this.options.cancel == "string" ? $(a.target).hasClass('ui-icon-closethick') : false);

Thats the trick! If we check the existence of the class, everything is fine and fast...

Greets,

Patrick

[Scott González]

@omage2k: hardcoding a dialog setting in mouse would break a million things.

[omega2k]

Replying to scott.gonzalez:

@omage2k: hardcoding a dialog setting in mouse would break a million things.

Thats right, but the UI-Class itself assigns the class "ui-icon-closethick", isn't it? What other Cancel-Buttons do exist? Maybe a Regex or multi-selector would be better...

Please, could you explain me the whole function of:

$(event.target).parents().add(event.target).filter(this.options.cancel).length

Why climbing up the DOM-tree, adding the same object again and then filter for cancel-option?

[Scott González]

The cancel option is a generic option that allows canceling mouse interactions. Look at the documentation for draggable to see what it's doing.

[Scott González]

Core ticket: ​http://bugs.jquery.com/ticket/7341 (closed as wontfix)

[fracmak]

This is a duplicate of #7118

I've attached a pull ticket to solve this issue by bypassing the .add function and instead adding a selector to the .parents() call and using a .is() on the event.target.

​https://github.com/jquery/jquery-ui/pull/309

[Scott González]

Duplicate of #7118.