Ticket #5405 (closed bug: fixed)

Opened 5 years ago

Last modified 5 years ago

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:
Blocking: Blocked by:

Description (last modified by joern.zaefferer) (diff)

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

mousedownfix-5405.patch Download (635 bytes) - added by joern.zaefferer 5 years ago.
Patch to cancel blur-closing-timeout on mousedown on menu

Change History

comment:1 Changed 5 years ago by scott.gonzalez

  • Status changed from new to closed
  • Resolution set to worksforme

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

comment:2 Changed 5 years ago by darthj

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); } });

comment:3 Changed 5 years ago by tee_emm_eff

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.

comment:4 Changed 5 years ago by scott.gonzalez

  • Status changed from closed to reopened
  • Resolution worksforme deleted

comment:5 Changed 5 years ago by briano

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.

comment:6 Changed 5 years ago by buvinghausen

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.

comment:7 Changed 5 years ago by buvinghausen

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.

comment:8 Changed 5 years ago by jeremydorn

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

comment:9 Changed 5 years ago by lambacck

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.

comment:10 Changed 5 years ago by jeremydorn

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.

comment:11 Changed 5 years ago by preachergeek

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.

comment:12 Changed 5 years ago by joern.zaefferer

  • Priority changed from major to critical
  • Version changed from 1.8 to 1.8.1
  • Description modified (diff)
  • Summary changed from Autocomplete select sporadically not work to Autocomplete: select event not triggered when mousedown duration > blur timeout

Changed 5 years ago by joern.zaefferer

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

comment:13 Changed 5 years ago by joern.zaefferer

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.

comment:14 Changed 5 years ago by lambacck

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.

comment:15 Changed 5 years ago by joern.zaefferer

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:16 Changed 5 years ago by rdworth

  • Milestone changed from 1.9 to 1.8.2

comment:17 Changed 5 years ago by nickknw

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

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

comment:18 Changed 5 years ago by scott.gonzalez

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

Note: See TracTickets for help on using tickets.