keymanapp/keyman

bug(android): The globe key shows in an enabled state after selecting a default keyboard from the "Keyboard Picker."

dinakaranr opened this issue · 1 comments

dinakaranr commented

Describe the bug

The globe key shows an enabled state after selecting a default keyboard from the "Keyboard Picker." This problem appears only if Keyman has more than one keyboard.

Reproduce the bug

Steps to reproduce:

  1. Installed the "Keyman-17.0.325.apk" stable file and gave all permissions to the application.
  2. Checked the "Enable Keyman as system-wide keyboard" and set the keyboard as the default keyboard box on the settings page.
  3. Installed the "Khmer angkor" keyboard by clicking Settings/Install Keyboard/Install from keyman.com.
  4. Change the keyboard from Khmer to English by short-pressing the globe key.
  5. Open the "Keyboard Picker" dialog by long-pressing the globe key.
  6. Select the default keyboard (e.g., English) and then return to the keyman home screen.
  7. Here, the globe key appeared as an enabled state. It seems to be the wrong state of behavior.
    Please refer to the video file.
    https://github.com/keymanapp/keyman/assets/19683059/53922d78-ac08-4a77-b431-9e140212259f

Expected behavior

No response

Related issues

No response

Keyman apps

  • Keyman for Android
  • Keyman for iPhone and iPad
  • Keyman for Linux
  • Keyman for macOS
  • Keyman for Windows
  • Keyman Developer
  • KeymanWeb
  • Other - give details at bottom of form

Keyman version

Keyman-17.0.325 stable

Operating system

No response

Device

No response

Target application

No response

Browser

No response

Keyboard name

english_eurolatin_sil

Keyboard version

No response

Language name

English

Additional context

No response

jahorton commented

The issue is that the picker-triggering longhold is triggered by Android code, and the picker triggers an Android-side change that pushes a new View / Activity to the front... interrupting the standard event flow. We don't get the "key up" event.

Things pass through here:

Android-side gesture detector method:

keyman/android/KMEA/app/src/main/java/com/keyman/engine/KMKeyboard.java

Lines 312 to 317 in d699209

@Override
public void onLongPress(MotionEvent event) {
if (KMManager.getGlobeKeyState() == KMManager.GlobeKeyState.GLOBE_KEY_STATE_DOWN) {
KMManager.setGlobeKeyState(KMManager.GlobeKeyState.GLOBE_KEY_STATE_LONGPRESS);
KMManager.handleGlobeKeyAction(context, true, keyboardType);
return;

On the way to here, eventually:

keyman/android/KMEA/app/src/main/java/com/keyman/engine/KMManager.java

Lines 539 to 555 in bed7711

private static void doGlobeKeyLongpressAction(Context context, KeyboardType keyboard) {
if (keyboard == KeyboardType.KEYBOARD_TYPE_INAPP) {
if (InAppKeyboard == null || !InAppKeyboard.keyboardPickerEnabled) {
return;
}
} else if (keyboard == KeyboardType.KEYBOARD_TYPE_SYSTEM) {
if (SystemKeyboard == null || !SystemKeyboard.keyboardPickerEnabled) {
return;
}
} else {
// assertion failure?
KMLog.LogError(TAG, "doGlobeKeyLongpressAction with keyboard type " + keyboard);
return;
}
showKeyboardPicker(context, keyboard);
}

As things are, Web will naturally recover and cancel the globe-key highlighting on the next keypress regardless, even without a fix. It's not the prettiest situation, though. The best and cleanest way to "fix" this is to add a new call into JS to clear active highlighting whenever the picker is activated, given the moving parts involved.

  • 👍1