Autocomplete: mousing over menu option replaces text box contents, moves caret
|Reported by:||triblondon||Owned by:|
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):
- Open the multiple-select demo in Safari or Chrome (tested in Chrome 5.0.375.125):
- Type 'sand' into the birds box. Wait for completions
- Click between the 's' and the 'a' to place the caret like this: s|and.
- Move the mouse cursor over the items in the suggestions list.
- Observe that the caret jumps to the end of the text box.
Steps to reproduce (code):
- Perform step 1 above
- Set a breakpoint at line 138 of revision cb7eb69973c62f26bcde0325a33a5c837bc9b5e9 of jquery.ui.autocomplete.js
- Perform steps 2-4 above
- 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.
- Reverse the changes made in these changesets:
- Find a new solution to
http://dev.jqueryui.com/ticket/5349 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 :-)
Change History (7)
comment:2 Changed 5 years ago by scott.gonzalez
- Component changed from ui.core to ui.autocomplete
- Milestone changed from TBD to 1.9
- Resolution set to fixed
- Status changed from new to closed
comment:3 Changed 5 years ago by triblondon
- Resolution fixed deleted
- Status changed from closed to reopened
comment:4 Changed 5 years ago by scott.gonzalez
- Resolution set to fixed
- Status changed from reopened to closed