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

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

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.

$("#suchfeld").autocomplete({

source: "/obj/searchThema",

minLength: 2,

select: function(event, ui) {

window.location.href = "/Kunstgeschichte/index/" + ui.item.id;

$('#suchid').val(ui.item.id);

}

});

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.

We are having the same problem as well.

This is even reproducible with the JQuery UI Autocomplete demo "Remote JSONP datasource": http://jqueryui.com/demos/autocomplete/#remote-jsonp

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 ui.menu 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: this.active });

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

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.

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.

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 http://jeremydorn.blogspot.com/2010/04/fixing-jquery-ui-autocomplete.html

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.

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(self.menu.clicking) return;
  	     ...

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

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.

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.

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.

Fixed by http://github.com/jquery/jquery-ui/commit/fc093e9feb4450b1ab93e3da9a2f7abb1d4335b5

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

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

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