Atlaskit Single-Select component - unexpected or buggy behaviour

I’m looking at using a Heading-less Single-Select drop-down list component with hasAutocomplete enabled but have discovered the following 4 unexpected behaviours:

On the component demo area for the With Autocomplete example using keyboard only…

  1. Selecting anything from the City section then trying to select Sheep initially doesn’t work if using just the keyboard.

  2. Selecting the Item that has no Heading will happen when you think you’ve selected the disabled item so it seems item placement is getting mixed up inside their component (can happen with mouse too)

  3. The currently selected item is being removed from the list of selection options, which creates confusion.

  4. When selecting a different item, headless ones cause the blue selection to vanish so you don’t know what’s selected… if anything.

It’s like there are invisible items in the table it’s pretty strange.

Link to demo area:

At a best guess i’d say the observed glitches stem from 2 things -> Heading-less items and selected items being kind of removed from the list

@murrays - I tried it myself, and also experienced the behavior. I’ve pinged the team that’s closest to this to take a look.

1 Like

Hello @murrays,

Thanks for reporting this,

  1. What is your use case and steps? When I tab then press arrow down once the menu opens and press arrow down again then select ‘Sheep’ and press Enter - it works.
  2. I am not able to reproduce it - I am not able to select disabled item, the menu stays open.
  3. This is the expected behavior for the component, it will change with the new select component :
  4. In which example does it happen in the stateless? it sounds like a focus bug.

in general can you provide us with a codesandbox: - you can raise an issue there : too, will be easier to follow

Thanks in advance,

Thanks @nmansilla.

Hi @rbellebon,

  1. My use case is having a single, heading-less drop list with autoComplete enabled so a user can type in a partial selection and see all that match (which I would expect includes the one that was previously selected if it matches the new string of text entered by a user).

What actually happens is that the currently selected option is not displayed in the list of matching single-select options available even when it would be a match.

To replicate the behaviour, I simply click on the drop down list to open it, arrow key down till Sheep is selected and try pressing the Return key… which does nothing.

  1. It isn’t that you are selecting the disabled item but the selection marker sits over it and when clicked is selecting the heading-less item below it.

  2. So this behaviour will be changing then to include all selection options in a Single-Select droplist when a user attempts to select a new option as that would be ideal.

  3. This happens in the with autoComplete example when using the down arrow on the opened list, selecting either a Heading item causes the selection marker to go invisible or selecting a heading-less item will have the same outcome.

(video below is using down arrow attempting to select Sheep without it working and shows when selection box vanishes on headings and that selecting an invisible heading selects Sheep.)

Ok. I am able to reproduce it with Autocomplete. I’ll see what we can do


Awesome thank you for looking into this for us.

Hello @murrays, it looks like we have couple of bugs on our end already tracked describing the behavior you mentioned. Unfortunately, they may not be fixed in the single select but in the new select component coming soon.

Hi @rbellebon thanks for getting back about this with that info.

Will the underlying API in how we use the new single-select component work the same or will there be refactor impacts if we’ve been using the current one?

it will be quite similar, you can have a look there: