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(android/engine): Fix sticky long-press keys #6637
Conversation
User Test ResultsTest specification and instructions
Test Artifacts |
|
|
TEST_BETA_STICKY_KEYS should have shown a long-press key getting stuck. Like quickly typing y multiple times and release sometimes results in the long-press keys being displayed. @keymanapp-test-bot retest TEST_BETA_STICKY_KEYS |
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.
LGTM. Nice clean update.
@bharanidharanj - TEST_BETA_STICKY_KEYS is expecting the long-press key to be stuck (a bug), but the test itself should PASS if you see the bug. I'll edit the step to expect that. @keymanapp-test-bot retest TEST_BETA_STICKY_KEYS |
@darcywong00 Okay, Thanks for the Clarification. |
|
Changes in this pull request will be available for download in Keyman version 15.0.251-beta |
Fixes #6981. Longpress menus were being triggered on any detected movement on keys on Android. This would cause rapid typing to periodically fail as the user would make a single-pixel movement while typing, which would then block subsequent key events. This issue was introduced in #6637, which resolved a somewhat related problem with sticky longpress menus. The fix is in three parts: 1. Remove the touch movement detection which caused the primary problem 2. Address some logic issues around visibility of `subkeysWindow` 3. Introduce a new 'scroll' gesture handler which detects a negative-y movement above a 5px threshold, to open the longpress menu. The 5px threshold is the minimum default used by Keyman Engine for Web. However, it may not be ideal, and we should consider moving to using the 0.25 x row height value that Keyman Engine for Web uses in a future update. However, I do not consider this to be a reason to block this fix, as it would require significant extra engineering.
Fixes #6981. Longpress menus were being triggered on any detected movement on keys on Android. This would cause rapid typing to periodically fail as the user would make a single-pixel movement while typing, which would then block subsequent key events. This issue was introduced in #6637, which resolved a somewhat related problem with sticky longpress menus. The fix is in three parts: 1. Remove the touch movement detection which caused the primary problem 2. Address some logic issues around visibility of `subkeysWindow` 3. Introduce a new 'scroll' gesture handler which detects a negative-y movement above a 5px threshold, to open the longpress menu. The 5px threshold is the minimum default used by Keyman Engine for Web. However, it may not be ideal, and we should consider moving to using the 0.25 x row height value that Keyman Engine for Web uses in a future update. However, I do not consider this to be a reason to block this fix, as it would require significant extra engineering.
Fixes #6636
The logic to clear popup keys depends on GestureDetector triggering
MotionEvent.ACTION_UP
. This PR pulls the handling out of the if/else because sometimes, theACTION_UP
event goes through the if() block.keyman/android/KMEA/app/src/main/java/com/tavultesoft/kmea/KMKeyboard.java
Lines 285 to 289 in 1747722
User Testing
Setup - A physical Android device. Don't use emulator because the scenario involves typing fast on the OSK (e.g. two thumbs)
https://downloads.keyman.com/android/beta/15.0.249/keyman-15.0.249.apk