User Test Results

Test specification and instructions

• ✅ TEST_KEYBOARD (PASSED) (notes)

Test Artifacts

• Android
  • Keyman for Android apk
  • FirstVoices for Android 16.0 apk
  • FirstVoices Keyboards for Android apk
  • KeyboardHarness apk
  • Keyman for Android 16.0 apk
  • KMSample1 apk
  • KMSample2 apk

I am uncertain about the ramifications of this change. This means the Runnable runs on a new thread, not the UI thread, which seems to go against the discussion in the previously linked SO post. Can you elucidate?

I was just returning the call to how it had been for stable-15.0

I was just returning the call to how it had been for stable-15.0

OK, so this was changed because of reported errors -- see #7612 (comment):

True. Note that I placed it here because I saw a corresponding error occur once during development. Thought that was interesting, since "shouldn't the code be doing this already?"

I would like to understand why this is causing the event handlers not to attach -- is it because there is no UI thread when the keyboard is hidden?

Test Results

I tested this issue with the attached "Keyman 18.0.108-alpha-test-12381" build on the Android 14 mobile (physical device and keyboard connected with USB cable). I am sharing my observation.

TEST_KEYBOARD (Passed):

1. Installed the "Keyman-18.0.108.apk" file from the PR build. 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. Open the Keyman app. Enable the "Predictions" to install the "Dictionary."
4. Launch the Google Keep application.
5. Create a new note. Keyman "sil_euro_latin" was selected as the system keyboard.
6. Typed some text using the "sil_euro_latin" keyboard.
7. Verified the system keyboard types fine when doing long presses, switching, keys, and pull-down. 
8. Type `a in the physical keyboard, and OSK appears at the same time. 
9. Verified the text appeared as à.
10. Disabled the OSK by selecting "Language and Keyboard" --> Physical keyboard --> Toggle "show the on-screen keyboard."
11. Again, launch the Google Keep application.
12. Create a new note.
13. Verified that the OSK does not appear in the Android mobile app.
14. Type `a in the physical keyboard.
15. Verified the text appeared as à.
    It works well using the physical keyboard if OSK is enabled or disabled.
    I tested this same scenario in the "https://editpad.org/" on the Chrome browser. It works great for me.

is it because there is no UI thread when the keyboard is hidden?

That's what seems to be the behavior

When the OSK is hidden, executing hardware keystrokes never gets into this handler on the right. And I see the javascriptAfterLoad queue keeps accumulating the Javascript calls.

When the OSK is shown again, all the Javascript calls execute and the text updates.

This reversion may appear to work but it is not thread safe -- which is probably why it was changed in the first place. Calling this.postDelayed() is scheduling it to run on the UI thread (per the documentation). But calling new Handler().postDelayed() schedules it to run on a new thread.

1. I guess this could cause the error "All WebView methods must be called on the same thread." (per the Stack Overflow discussion). Because now we are calling WebView methods from the wrong thread, right? (We'll only see it happen if javascriptAfterLoad.size() > 0.
2. In the runner, we are referencing parent object member variables that could be being modified by another thread, e.g. javascriptAfterLoad, keyboardSet. This will likely lead to thread races -- access to these members needs to be sychronized.
3. Also all calls to member functions are on the wrong thread, as they expect to be called on the UI thread, e.g. loadUrl, callJavascriptAfterLoad.
4. It is possible, albeit probably unlikely, that the runner could execute after the parent object is destroyed, resulting in a crash.

So we need to find a better way to solve this.