Please look at the image I've attached.

If somebody types some text in an autocomplete textfield, say 'ed' but then types a space, the suggestions with 'edX' where X is not a space, still show up, whereas only the suggestions where 'ed ' (note the space) should only be displayed.

A minor bug, however most autocomplete textfield systems work this way, and I believe it is right for it to work this way.

So in the image attached, when I type 'ed' the suggestions shown in the image should display, but when I type the space, the '4 bedroom' items should not show up in the suggestions.


CatsFromStonehenge created an issue. See original summary.

CatsFromStonehenge’s picture

Issue summary: View changes
cilefen’s picture

Component: field system » base system
Issue tags: -autocomplete +JavaScript
droplet’s picture

Category: Bug report » Task
Issue tags: +Usability, +accessibility

It's not a bug. We trimmed it as expected. I don't know if we want to do that or not.

CatsFromStonehenge’s picture

It's non-standard behaviour though. Try using jQuery autocomplete as default, or try using the autocomplete on

It's not intuitive to the user, and I'd say it's not good user interface design.

I'd call it a design bug. Apologies to disagree, but it really is non-standard, unexpected behaviour. Please don't be one of those developers that takes any feedback as 'not a bug' because they can't be bothered to fix it.

cilefen’s picture

@CatsFromStonehenge: @droplet is a maintainer of JavaScript in Drupal core, representing countless hours of writing code, meetings, issue reviews, code sprints, and more. I ask you to consider those facts when you comment.

alexpott’s picture

@CatsFromStonehenge: @droplet wrote:

I don't know if we want to do that or not.

I think the change from bug to task was to indicate that the trimming was a choice. @droplet was not saying that exploring the UX and accessibility implications of the behaviour in HEAD shouldn't occur.

One argument to make this change is that unrelated words make up other words so "cat" suggests both "cat" and "cathode ray tube" whereas "cat " would eliminate "cathode ray tube". And the user has entered a space so by trimming we are ignoring user intention. Which does not seem to be the best UX.

@CatsFromStonehenge: Additionally since Drupal is open source anyone is free to propose a patch for community consideration. It does not have to be @droplet, or anyone else, it could be you!

alexpott’s picture

Issue summary: View changes
24.18 KB

What is interesting is that it looks like the history of the trimming comes from the usage for taxonomy term lookups. This makes the auto-complete quite inappropriate for nodes where titles have commas.

Steps to reproduce:

  1. Install standard
  2. Add a node reference field to the page content type that can reference content of the type page
  3. Create a page with the title "Live, Die, Repeat"
  4. Create another page with the title "Die, Repeat"
  5. Create to node/add/page and put ""Live, Die" in the autocomplete box for the node reference field... you'll see:
    funky autocomplete

We really should also check the issue queue for pre-existing issues.

droplet’s picture

It has few problems to consider:

1. Trailing SPACE
`ABC `

2. Leading SPACE
` ABC'

3. Multiple tagging
`ABC ,ORANGE` (Note, we normalized it as `ABC , ORANGE` when it re-rendering from backend)

4. More complicated issue:
We typed

now go back to `ABC` tag and type D

Should we consider there's a TRAILING SPACE OR not?

5. Place the mouse after last letter
`ABC `

We able to place mouse cursor after C. Now the SPACE is invisible. It's another UX problem

The trimming on it was a way to normalize the result set I think.

(It implied a huge API changes/issues on \Drupal\Component\Utility\Tags.)

miwayha’s picture

It's worth referencing the relevant ARIA spec: The relevant text states:

Indicates whether user input completion suggestions are provided.

The spec doesn't indicate how the provided suggestions should be determined. So I don't think it's fair to say that any of the alternative implementations are "right" or "wrong" (since neither violates the spec) so much as they might be "appropriate" or "inappropriate" for a given case. I'd support removing the accessibility tag on this issue and having it be tested for usability.

droplet’s picture