Skip to main content

Search and Top Navigation

#5900 closed bug (fixed)

Opened August 04, 2010 04:48PM UTC

Closed August 04, 2010 07:52PM UTC

Last modified November 19, 2010 06:26PM UTC

Autocomplete: mousing over menu option replaces text box contents, moves caret

Reported by: triblondon Owned by:
Priority: minor Milestone: 1.8.4
Component: ui.autocomplete Version: 1.8.3
Keywords: Cc:
Blocked by: Blocking:

I'm building a search bar with per-term autocomplete similar to the "multiple values, remote" demo on the docs. I've noticed that when the mouse enters or leaves any item in the suggestion list, the menu widget's blur event is fired, which has a callback in the autocomplete that places the current value of the search term into the text field.

This seems fairly pointless to me since the search term is the current contents of the text field, so you're just writing over the text field contents with an identical string, however this does cause a problem in webkit browsers, because replacing the contents of the text field moves the caret to the end of the text field, which makes using the autocomplete in a multi-select use case impossible.

Steps to reproduce (visual):

1. Open the multiple-select demo in Safari or Chrome (tested in Chrome 5.0.375.125):

2. Type 'sand' into the birds box. Wait for completions

3. Click between the 's' and the 'a' to place the caret like this: s|and.

4. Move the mouse cursor over the items in the suggestions list.

5. Observe that the caret jumps to the end of the text box.

Steps to reproduce (code):

1. Perform step 1 above

2. Set a breakpoint at line 138 of revision cb7eb69973c62f26bcde0325a33a5c837bc9b5e9 of jquery.ui.autocomplete.js

3. Perform steps 2-4 above

4. Observe that the breakpoint fires, with self.element.val() already equal to self.term (in some cases it is not, because the text field value has been replaced by the hovered menu item, and this statement therefore sets it back to the original search text in an attempt to fix the bug raised in ticket #5349).


Comment out the offending line. I have not found a workaround that doesn't involve source hackery on the autocomplete source.

Solution suggestions:

  • Reverse the changes made in these changesets:

  • Find a new solution to

possibly by hooking the focus event - in my use case I am returning false from my focus handler, thereby avoiding the bug raised in ticket 5349. But it seems sensible that the solution to the text field's value being replaced by something unwanted would be to stop that happening rather than subsequently putting the original value back and causing this new problem in the process :-)

Attachments (0)
Change History (7)

Changed August 04, 2010 04:52PM UTC by triblondon comment:1

Sorry I should have chosen component ui.autocomplete when creating that ticket. Could a mod please update.

Changed August 04, 2010 05:28PM UTC by scottgonzalez comment:2

component: ui.coreui.autocomplete
milestone: TBD1.9
resolution: → fixed
status: newclosed

Fixed in ed07f0a.

Changed August 04, 2010 07:32PM UTC by triblondon comment:3

resolution: fixed
status: closedreopened

Scott, I appreciate the rapid fix, and this'll enable me to revert to official code, which is great.

However, I don't agree that this is a complete solution. It only works if you return false from a function attached to the focus event. If you don't, the default behaviour of the widget on focus is to replace the contents of the text field with the focussed suggestion, which will prevent any well implemented multiple-select autocomplete fields from working correctly. That's my understanding, though I've not actually tested that behaviour as it's irrelevant to my use case, but thought it worth flagging.

Thanks for the fix anyway. Certainly solves my problem.

Changed August 04, 2010 07:52PM UTC by scottgonzalez comment:4

resolution: → fixed
status: reopenedclosed

Hovering items with the mouse does not alter the text field at all. Using the keyboard to navigate the menu does, but you're going to lose your cursor position in that case anyway.

Changed August 04, 2010 08:06PM UTC by triblondon comment:5

OK, that seems fine then.

Changed August 06, 2010 12:22AM UTC by scottgonzalez comment:6


Changed November 19, 2010 06:26PM UTC by Scott González comment:7

Autocomplete: Don't reset text field value on blur unless it will actually change the value. Fixes #5900 - Autocomplete: mousing over menu option replaces text box contents, moves caret.

Changeset: ed07f0a05656d2c66db453c8f6d664f69ec1a04d