Skip to main content

Search and Top Navigation

#5405 closed bug (fixed)

Opened March 23, 2010 07:22AM UTC

Closed May 18, 2010 01:01PM UTC

Last modified May 27, 2010 05:36PM UTC

Autocomplete: select event not triggered when mousedown duration > blur timeout

Reported by: darthj Owned by:
Priority: critical Milestone: 1.8.2
Component: ui.autocomplete Version: 1.8.1
Keywords: Cc:
Blocked by: Blocking:

Menu triggers a select-event on mouse-click, while Autocomplete starts a timeout on blur with just 150ms. If the user's mousedown duration is higher than that timeout, then select-event is never triggered.

Increasing the blur-timeout-duration would just make the problem occur less often. A preferable solution wouldn't need the timeout at all.

Attachments (1)
  • mousedownfix-5405.patch (0.6 KB) - added by jzaefferer May 15, 2010 02:20PM UTC.

    Patch to cancel blur-closing-timeout on mousedown on menu

Change History (18)

Changed March 23, 2010 06:12PM UTC by scottgonzalez comment:1

resolution: → worksforme
status: newclosed

That page is working fine for me. Please provide more details if you continue having problems.

Changed March 24, 2010 01:21PM UTC by darthj comment:2

Please put in Kreuzigung and click on the first entry. - In 90 Percent of all clicks its not working. - You were not redirected. I used this code here for autoceomplete widget.


source: "/obj/searchThema",

minLength: 2,

select: function(event, ui) {

window.location.href = "/Kunstgeschichte/index/" +;




Changed March 25, 2010 05:00AM UTC by tee_emm_eff comment:3

I'm having the same problem here. On this page you'll always see debug output printed when the select function is triggered. The problem only occurs when you use the mouse to click a menu item, not when you use the keyboard.

It can be reproduced by holding down the mouse button longer. When you do a very fast click, select will always be called. When you hold down the mouse button for something like 200-400 ms, the menu goes away and there's no select call. There's some threshold of mouse-down duration before which select is called and after which it isn't.

I verified this same behavior occurs on darthj's page.

Changed March 26, 2010 02:20PM UTC by scottgonzalez comment:4

resolution: worksforme
status: closedreopened

Changed March 26, 2010 02:55PM UTC by briano comment:5

We are having the same problem as well.

This is even reproducible with the JQuery UI Autocomplete demo "Remote JSONP datasource":

Just type "New York" and either click quickly or click and hold, and notice that with a quick click, New York gets added to the list below, and with a click and hold, it does not.

It looks like the problem is in jquery.ui.autocomplete.js in the widget. It tracks the "active" item based on mouseenter and mouseleave events of the items. For some reason that I haven't determined, on mousedown, the menu disappears. I suspect that this leads to a mouseleave event, which in turn causes deactivate to be called, because when select() is called on mouseup (when the click event completes) it does:

this._trigger("selected", null, { item: });

and is null at that point. If you click quickly enough that the mouseup happens before the mouseleave, then is still set, and it works.

Changed April 11, 2010 01:52AM UTC by buvinghausen comment:6

This bug basically makes the AutoComplete worthless because users have been getting angry at me "the page doesn't load the data!!!!" It's hard to tell a large section of your user base "you are not releasing the mouse button quick enough when you click"

I'm now in the process of searching for the best plug-in that doesn't have this limitation and will try to use it instead.

Changed April 11, 2010 03:26AM UTC by buvinghausen comment:7

FWIW I decided to stick it out with the jQuery UI AutoComplete but I did create a workaround that will at least meet my needs.

Basically I declare a select fired variable & temp variables to assign on focus

my open handler sets that value to false & blow away temporary variables

my focus handler assign values to temporary variables

my close handler checks to see if select fired = false and see if the temporary key variable has a value (something went under focus) then go ahead and fire a the same event as the select

my select handler sets the select fired variable to true to prevent duplicate loads

An obvious side effect of this pattern is you can focus over items and then you mouse away from the AutoComplete and click somewhere else entirely and it will still trigger a load. The way I see it that will generate far fewer complaints so for now that's simply how I'm going to handle it until this gets resolved the right way.

Changed April 12, 2010 08:11AM UTC by jeremydorn comment:8

I did something similar to buvinghausen to fix the problem.

I'm storing the item in a temporary variable as it is focused and I attached a mousedown event to the autocomplete widget that uses that. I'm also triggering the mousedown event when an object is selected so it still works with the keyboard.

This works because the mousedown event fires before the autocomplete widget closes. The only real downside I can see is that users generally expect things to happen when they release a mouse button, not when they first press it.

I put up some code examples at

Changed April 13, 2010 02:48AM UTC by lambacck comment:9

I did a little testing since I too would like to see this bug fixed.

In the blur.autocomplete handler on line 86 a timeout is created. If the mouseup happens before the timeout, then the select event fires, otherwise, the timeout closes the menu and causes the menu blur and preempting the select event.

The code says that finding a way to not use the timeout is an item on the todo list. I would say the todo item is getting more urgent. Unfortunately, I don't think I understand the code enough at this point to propose a fix.

Changed April 15, 2010 06:20PM UTC by jeremydorn comment:10

The problem may lie with the menu widget. The menu is triggering select on the click event, which doesn't fire until the mouse is released. If "click" is changed to "mousedown" at line 335, it fixes the problem.

Another possible solution is to add a "clicking" attribute to the menu widget, which is set to true on mousedown and set to false on mouseup. Then, you could check for this attribute at line 86 with something like:

86	.bind( "blur.autocomplete", function( event ) {
87	     if( return;

With this approach, the menu widget's behavior is not altered.

Changed April 18, 2010 06:27PM UTC by preachergeek comment:11

While we await a fix, it would appear that merely increasing the timeout on line 89 from its current value of 150ms to some value like 1500ms would take care of the "slow clickers" amongst our users.

Changed May 15, 2010 02:07PM UTC by jzaefferer comment:12

description: try this link. In the left slot "Themensuche" sometimes select doesn't work. - I think thats a bug. \ \ triggers a select-event on mouse-click, while Autocomplete starts a timeout on blur with just 150ms. If the user's mousedown duration is higher than that timeout, then select-event is never triggered. \ \ Increasing the blur-timeout-duration would just make the problem occur less often. A preferable solution wouldn't need the timeout at all.
priority: majorcritical
summary: Autocomplete select sporadically not workAutocomplete: select event not triggered when mousedown duration > blur timeout

Changed May 15, 2010 02:22PM UTC by jzaefferer comment:13

I've attached a patch that introduces more event handlers and timeouts to address this issue, and based on my limited testing, seems to fix the issue.

I don't know how to write a unit test for the issue, as I don't see a way to simulate a click event with a long mousedown-duration, so having someone test this before I commit it would help.

Changed May 16, 2010 12:47AM UTC by lambacck comment:14

The mousedownfix-5405.patch seems to work for my site. I was able to click and hold indefinitely and the selection occurred on mouse-up.

Changed May 18, 2010 01:01PM UTC by jzaefferer comment:15

resolution: → fixed
status: reopenedclosed

Changed May 20, 2010 11:15AM UTC by rdworth comment:16


Changed May 27, 2010 05:03PM UTC by nickknw comment:17

mousedownfix-5405.patch works great for me too, thanks joern.

Just to confirm, this fix will be in 1.8.2, is that right?

Changed May 27, 2010 05:36PM UTC by scottgonzalez comment:18

Yes, this is fixed in 1.8.2, which has already been tagged, but not released.