Autocomplete used on a single value field should not split input on commas

I opened this PR with some initial work done on the JS side, it basically just avoids splitting the string if the form element has the data-autocomplete-single attribute.

Facing this exact issue, very glad to see some work has been done on this already, thanks @alecsmrekar

In my instance my Autocomplete field is replacing only the part of the string *after* the last comma. For example:

1. Searching for "phrase with, commas".
2. Select one of the autocomplete results, e.g. "Longer phrase with, commas"
3. The field value is then set to "phrase with, Longer phrase with, commas".

Patch in #21 is working for me. After applying the patch and adding the `data-autocomplete-single` attribute to my field the full value is replaced:

1. Searching for "phrase with, commas".
2. Select one of the autocomplete results, e.g. "Longer phrase with, commas"
3. The field value is then set to "Longer phrase with, commas".

I think that happens in

  function selectHandler(event, ui) {
    const terms = autocomplete.splitValues(event.target.value);
    // Remove the current input.
    terms.pop();
    // Add the selected item.
    terms.push(ui.item.value);

Which should probably become something like this pseudo code:

  function selectHandler(event, ui) {
    const terms = autocomplete.splitValues(event.target.value);
    if ( is single ) {
      // Remove all inputs, the field only allows one selection.
      terms. remove all of them();
    }
    else {
      // Remove the current input only.
      terms.pop();
    }
    // Add the selected item.
    terms.push(ui.item.value);

I think Patch #21 already delivers on that change.

autocomplete.splitValues defined here:
https://git.drupalcode.org/project/drupal/-/blob/1efbc4ec5b4ccd770e51e77...

Fires autocompleteSplitValues from here:
https://git.drupalcode.org/project/drupal/-/blob/1efbc4ec5b4ccd770e51e77...

Which has the change:

    if (autocomplete.options.isSingle) {
      return value ? [value] : [];
    }

Okay confirm you are saying this is working then already as is with single. So the next step here is to confirm with test coverage. Changing to NW given there is an MR

Updated issue summary to cover Graham's issue that is also fixed by this.

A client just ran into this, I agree this is confusing UX, especially if you use both: Autocomplete and Tags-Style for different use-cases in the same project.

I've installed the patch from #21 on our Drupal 10.4 site, and it has not resolved the problem.

I did some debugging, and found that on the Javascript side, everything is handled nicely with the patch in place. It is now returning "Apples, and Bananas" instead of just "and Bananas".

But on the Drupal side, it's still not working. handleAutocomplete() in html/core/modules/system/src/Controller/EntityAutocompleteController.php looks like this:

  public function handleAutocomplete(Request $request, $target_type, $selection_handler, $selection_settings_key) {
    $matches = [];
    // Get the typed string from the URL, if it exists.
    $input = $request->query->get('q');
    // Check this string for emptiness, but allow any non-empty string.
    if (is_string($input) && strlen($input)) {
      $tag_list = Tags::explode($input);
      $tag_list = [$input];
      $typed_string = !empty($tag_list) ? mb_strtolower(array_pop($tag_list)) : '';

$input starts out as "Apples, and Bananas", but Tags::explode breaks it on the comma, and then $typed_string ends up with only "and Bananas".

This is the value that is then passed (at the end of that same function) into the matcher, which results in autocomplete results that ignore what came before the comma:
$matches = $this->matcher->getMatches($target_type, $selection_handler, $selection_settings, $typed_string);

When I replace $tag_list = Tags::explode($input); with $tag_list = [$input];, it works, for this one autocomplete field I am trying to debug. But of course that removes the multi-term handling functionality for the whole rest of the site.

I'm not sure how to proceed here. Any ideas?

Re: #29 - Right, that's the basic problem I foretold at #12. The backend needs to know about this, too. If the behavior is to be determined by field cardinality, we need some way for the Field API (which knows about field cardinality) to communicate with the Form API (which handles autocomplete) about how to handle commas.