Wrong item can be selected where the correct option's text also exists in other options.

[edwardhorsford]

I spotted a bug / poor handling where the wrong item can be selected if you're using autoselect and showAllValues.

Example:

In my example, each option has some common text appended. There's also an option that is just that text.

If you blur and focus the field again, that text is used as a search string and autoselect then selects the first entry.

The use case in my service is an autocomplete for people's names, with their team name in brackets. The team itself is also available to be selected.

I image similar could happen where any option's text also exists in other options - such as nested categories.

[tvararu]

Ah, this is because of the default search engine: https://github.com/alphagov/accessible-autocomplete/blob/3d7f093ac59b5d6cbd7972278a167eb7f3dc118e/src/wrapper.js#L14-L17

It takes an array of results and filters down to the ones that contain the query, in the same order. This happens both when you type in "apple" and also when you click on the autocomplete. It doesn't re-order them or do anything sophisticated.

A proper fix would be to modify the behaviour of the default engine but that would be a backwards incompatible change.

In the meantime, there's a couple of things you can try. The first is that if you pre-sort your options so that (apple) appears before John (apple), this bug should go away.

The second option is more involved, but you can override this behaviour with the source argument by passing in a customised engine. In this case, you could return results in a different order if you have an exact match:

const results = [
  'Banana',
  'Apricot',
  'Apple'
]

function suggest (query, populateResults) {
  // Filter the results that contain the query (case sensitive, probably not what you want) and *are not exactly matching*
  const filteredResults = results.filter(result => result.indexOf(query) !== -1 && result !== query)
  // Find the exact match if it exists
  const exactMatch = results.find(query)
  // Return results consisting of the exactMatch followed by all other results
  populateResults([exactMatch].concat(filteredResults))
}

(warning: hacky untested code that loops over the possible results twice which will be slow for extra large data sets but if you use extra large data sets you're probably doing something wrong, oh and it uses Array.prototype.find which doesn't work on IE, oh and it's not case insensitive like the default engine is)

[edwardhorsford]

@tvararu thanks for the suggested fixes.

In our service, showing (apple) is actually a separate bug - but it did help highlight this edge case.

[edwardhorsford]

I suspect this is a good reason for results to have some basic sorting - and always sort an exact match as the first result.