Opened 6 years ago

Closed 6 years ago

#9966 closed bug (wontfix)

Autocomplete change fails to pass selected Item if alert is opened inside of the select callback

Reported by: Melvin.Ross Owned by: Melvin.Ross
Priority: minor Milestone: none
Component: ui.autocomplete Version: 1.10.4
Keywords: Cc:
Blocked by: Blocking:

Description

This bug was actually previous reported here http://bugs.jqueryui.com/ticket/8847 , but was closed in part because the original reporter didn't fully identify what was causing the problem. After finding the report and reading the reporters last comment, I confirmed that his fiddle did in fact still not pass the selected item.

Here are two fiddles, based on the fiddle from the jquery.ui team member and the reporter. They're exactly the same except that in the faulty one the focus is taken away from the input field in the select callback. It can be taken away various ways (hence the commented out lines) and they all result in null being passed to the change event.

If the input is blurred by the user instead of by JS, it works just fine. I've tested on Firefox 24.4 and Chromium 33.

Working fiddle:http://jsfiddle.net/MelvinRoss/krc4f/1/ Not-working fiddle: http://jsfiddle.net/MelvinRoss/ET4RJ/4/

Change History (3)

comment:1 Changed 6 years ago by Scott González

Owner: set to Melvin.Ross
Status: newpending

Do you have a realistic scenario where this would occur?

comment:2 Changed 6 years ago by Melvin.Ross

Status: pendingnew

Here is fiddle mockup that mirrors what I'm doing using soda as an example http://jsfiddle.net/MelvinRoss/kQ3jG/2/.

Below is an outline of what my actual project is doing.

View looks like: There is a table with information about the logged in user as the header, under this there are two text inputs. The first is an address field, the second is a field is an ID field which designates the unique ID of that house.

Source: A user types in his address into the address field, and it hits google's maps API to show possible matches with autocomplete (for normalizaton).

Select: Once a user selects a normalized address, a dialog tells the user that this address is being looked up to find it's ID. This address is passed to a different API which returns IDs which are the source for the 2nd ID input box which also uses autocomplete. This dialog is dismissed when this data is returned and search is called on the 2nd input box.

Change: If Ui.item is null the customer put in an address and didn't select an option from the autocomplete list. Put the value of the address box into the header. Else, they picked something from the autocomplete list, put this into the header.

The dialog being created in the select callback takes the focus away from the address textfield, and thus the ui object passed into change is always null. Without the dialog, the user wouldn't know when the API call was finished.

Last edited 6 years ago by Melvin.Ross (previous) (diff)

comment:3 Changed 6 years ago by Scott González

Resolution: wontfix
Status: newclosed

You shouldn't use a dialog for this. You should just display the message inline near the text field.

Anything that moves focus away from the text field during selection isn't going to be supported.

Note: See TracTickets for help on using tickets.