Fix various "first press" bugs on single select dropdowns #1104
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 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. Fix the entire category of behavior by better evaluating what counts as a "printable" character.
|
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: |
|
Commenting to bump this PR, as these issues are pressing for our use of choices-js too. |
|
bump. This is a problem we also have. Ik hope someone can review this PR |
|
I have same issue. |
|
bump. Same issue. Retagging @mtriff to hopefull review/merge this PR |
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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+`,aon a mac, orWINKEY+.,aon 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:
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:
Types of changes
Checklist
(probably - no formal style guide)
I can't get Cypress to work, and unit tests don't seem appropriate. Pointers or recommendations welcome.