Open edwardhorsford opened 3 years ago
There is a similar issue raised in the govuk-country-and-territory repo https://github.com/alphagov/govuk-country-and-territory-autocomplete/issues/70
I've tested this issue using this page but wasn't able to replicate the issue. I tried the following steps:
and
@edwardhorsford Are you able to check if you're still seeing this issue and provide the exact steps you're taking so we can try to reproduce the issue, please? It would be good to know what browser you're using and what version of the autocomplete too.
@vanitabarrett I can't easily test this myself, but could do a screenshare with you?
Skimming the issue I suspect it directly relates to the accessibleAutocomplete.enhanceSelectElement({})
and possibly architectural decisions for the component.
With the enhanceSelectElement()
the autocomplete attempts to select the right option in the underlying select when you pick an item. This code doesn't run if you escape out of the field - even if the option is a caseless match.
Somewhat by design, when using this mode the raw value typed doesn't get submitted to the server (by default?). I think I've now come to the view this is the wrong decision, and when in this mode the autocomplete should either submit the value
for the selected select option, or else the free text typed if there is no match.
I'd stop bothering with trying to keep around the underlying select and keep it in sync - instead remove it and submit something using the same name.
To add some more context:
In the enhanceSelectElement()
mode, the autocomplete partially works like a select, but looks like an input.
I strongly think it should either:
At the moment we get the worst of both worlds - it looks like there's a value in the input, but it's not valid and won't even get sent to the server.
On my service, we've set up the autocomplete to always send the raw value typed to the server so we can compare it to the allowed values and act accordingly.
If a user types their answer in to the autocomplete rather than picking one - even if it's an exact match, that answer will not get submitted.
I'd consider this quite a serious bug - and am surprised we haven't come across it before. I assume on blur we should be checking the value and doing some stuff - but it seems like this only happens on interaction with the suggestions.
I've frequently observed users type complete answers in the autocomplete and not even realise suggestions were showing. Where the answers are short (eg 'French') they may well have typed the answer before ever noticing the suggestions.
There are some related bugs with this: