Ticket #5900 (closed bug: fixed)

Opened 4 years ago

Last modified 4 years ago

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

Description

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):

 http://jqueryui.com/demos/autocomplete/multiple-remote.html

  1. Type 'sand' into the birds box. Wait for completions
  1. Click between the 's' and the 'a' to place the caret like this: s|and.
  1. Move the mouse cursor over the items in the suggestions list.
  1. Observe that the caret jumps to the end of the text box.

Steps to reproduce (code):

  1. Perform step 1 above
  1. Set a breakpoint at line 138 of revision cb7eb69973c62f26bcde0325a33a5c837bc9b5e9 of jquery.ui.autocomplete.js
  1. Perform steps 2-4 above
  1. 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).

Workaround:

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:

 http://dev.jqueryui.com/changeset/2be46581da77440b88a9cd55a129c90c6af7a82d  http://dev.jqueryui.com/changeset/d2272f86bcc4f526f886f6b7846e34c0f1442c34

  • 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

comment:1 Changed 4 years ago by triblondon

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

comment:2 Changed 4 years ago by scott.gonzalez

  • Status changed from new to closed
  • Resolution set to fixed
  • Component changed from ui.core to ui.autocomplete
  • Milestone changed from TBD to 1.9

Fixed in  ed07f0a.

comment:3 Changed 4 years ago by triblondon

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:4 Changed 4 years ago by scott.gonzalez

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

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.

comment:5 Changed 4 years ago by triblondon

OK, that seems fine then.

comment:6 Changed 4 years ago by scott.gonzalez

  • Milestone changed from 1.9 to 1.8.4

comment:7 Changed 4 years ago by Scott González

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

Note: See TracTickets for help on using tickets.