Fix various "first press" bugs on single select dropdowns

[krisre-sigmabold]

I'm not able to fully test this PR against international languages, and there's a minor behavioral change worth explaining:

Previously, with a single select dropdown that has the focus, it would only be opened when a printable character was entered. This actually breaks the ability for the first character to be the result of a compose operation (e.g. à, entered via OPTION+` , a on a mac, or WINKEY+., a on windows)

Now, any keypress will open the select. This allows the following/follow-through characters to be received by the newly-opened-and-focused input box. It also supports things like pasting: entering the sequence "command+v" will have the effect "command opens the select, v pastes into it".

There is an additional bug still present that I wasn't able to figure out how to consistently reproduce. Some internal app state gets stuck in an inconsistent state and you're unable to type in the edit box. Clicking to focus it closes the dropdown, and keypresses are swallowed while it's open, but "keypresses that open" it get appended -- though when opening, the input element does not have focus.

Description

On OS X, pressing the command key while a Choices select is focused will add the text "meta". While looking into the details, I found quite a few more errors surrounding the "first keypress" behavior. When a closed single-select is focused, the following things generate incorrect behavior:

• Any key while shift was previously held: the first character is incorrectly capitalized/lowercased
• If the keypress begins a "compose" input (e.g. option+` on mac) the value will be "dead"
• Various other non-printable keys also emit output, such as the arrow keys, media keys, etc.

This PR fixes the entire category of behavior by better evaluating what counts as a "printable" character.

Related: #1072 #1068

Screenshots (if appropriate)

Example repro case:

• Visit https://choices-js.github.io/Choices/#:~:text=Remove%20item-,Single%20select%20input,-Default
• Press the tab key
• Press the "arrow up" key

Types of changes

• Chore (tooling change or documentation change)
• Refactor (non-breaking change which maintains existing functionality)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• My code follows the code style of this project.
  (probably - no formal style guide)
• I have added new tests for the bug I fixed/the new feature I added.
  I can't get Cypress to work, and unit tests don't seem appropriate. Pointers or recommendations welcome.
• I have modified existing tests for the bug I fixed/the new feature I added.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.

[zepfietje]

Are you able to review/merge this PR, @mtriff?

The bugs that this PR fixes have been reported a couple times in the @filamentphp framework too:

• Tabbing to searchable select input adds arrow text  filamentphp/filament#5989
• Cannot search select field when "Tab"ing into the field and typing a single character. filamentphp/filament#5924

[anticoagulant]

Commenting to bump this PR, as these issues are pressing for our use of choices-js too.

[erwingeiger]

bump. This is a problem we also have. Ik hope someone can review this PR

[ataknakbulut]

I have same issue.

https://prnt.sc/GI8blK8d6RKn

[BenBarreth]

bump. Same issue. Retagging @mtriff to hopefull review/merge this PR

[binaryfire]

Guys, @MrTIFF hasn't had any GitHub activity since Nov 2022: https://github.com/mtriff. So it's safe to say this package is no longer maintained.

There's a fork that seems to be active: https://github.com/formio/Choices. They've tagged a 10.2.1 version and the last commit was 2 months ago. I'd suggest seeing if they'll accept this PR instead.

[Xon]

Thanks! Implemented as part of #1166