-
-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(web): disabled autoaccept should not autohighlight suggestions #13068
Conversation
User Test ResultsTest specification and instructions Test Artifacts
|
if(this.predictionContext.selected == suggestion) { | ||
d.highlight(true); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we instead replace the if-condition with suggestion?.autoHighlight
, we can keep the "autocorrect hint" around in a cleaner way. Any interaction with the banner would instantly (and permanently) deselect it this way.
Test ResultsI tested this issue with the attached "Keyman-18.0.180-alpha-test-13068" build(29/01/2025) on Android 14(physical device). Here I am sharing my observation.
|
Changes in this pull request will be available for download in Keyman version 18.0.181-alpha |
I've written this PR in such a way that it should be fully compatible with #12893 when merged in.
There was no pre-existing issue for it, but I just realized that we still had a tiny bit of active autocorrect behavior enabled on
master
- the suggestion we would autocorrect to was being highlighted. It wouldn't trigger, but it could lead to "fun" cases where that suggestion and a touched suggestion would both be highlighted at the same time.Part of me... actually kind of liked having the autocorrect "hint" active, but this was definitely not intended.
User Testing
TEST_ANDROID_AUTOHIGHLIGHT: Using Keyman for Android and
sil_euro_latin
set to English, typetroub
and verify thattrouble
is not automatically highlighted.