Ticket #6644 (closed bug: duplicate)

Opened 4 years ago

Last modified 4 years ago

Select in Dialog causes slowness on IE8

Reported by: burgernofries Owned by:
Priority: minor Milestone: 1.9.0
Component: ui.dialog Version: 1.8.6
Keywords: Cc:
Blocking: Blocked by:

Description

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.

Change History

comment:1 Changed 4 years ago by scott.gonzalez

  • Priority changed from undecided to minor
  • Component changed from unfiled to ui.dialog
  • Milestone changed from 1.5 to 1.9

comment:2 follow-up: ↓ 5 Changed 4 years ago by 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...

Last edited 4 years ago by theoradu (previous) (diff)

comment:3 follow-up: ↓ 4 Changed 4 years ago by 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);

comment:4 in reply to: ↑ 3 Changed 4 years ago by 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.

comment:5 in reply to: ↑ 2 Changed 4 years ago by scott.gonzalez

  • Status changed from new to open

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.

comment:6 follow-up: ↓ 10 Changed 4 years ago by 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.

comment:7 Changed 4 years ago by rokclimb15

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

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

comment:8 Changed 4 years ago by 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?

comment:9 Changed 4 years ago by jebber007

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

comment:10 in reply to: ↑ 6 Changed 4 years ago by 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

comment:11 follow-up: ↓ 12 Changed 4 years ago by scott.gonzalez

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

comment:12 in reply to: ↑ 11 Changed 4 years ago by 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?

comment:13 Changed 4 years ago by scott.gonzalez

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

comment:14 Changed 4 years ago by scott.gonzalez

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

comment:15 Changed 4 years ago by 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

comment:16 Changed 4 years ago by scott.gonzalez

  • Status changed from open to closed
  • Resolution set to duplicate

comment:17 Changed 4 years ago by scott.gonzalez

Duplicate of #7118.

Note: See TracTickets for help on using tickets.