Fix various "first press" bugs on single select dropdowns

krisre-sigmabold commented 1 year ago

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.

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)
[x] 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

[x] 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.
[x] 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 commented 1 year ago

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:

anticoagulant commented 1 year ago

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

erwingeiger commented 10 months ago

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

ataknakbulut commented 10 months ago

I have same issue.

https://prnt.sc/GI8blK8d6RKn

BenBarreth commented 9 months ago

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

binaryfire commented 3 months ago

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.

Choices-js / Choices