OSK hides a half second after popping up on some input fields with zwp_text_input_v1 (Electron)

[Saviq]

Steps:

• tweak https://github.com/canonical/iot-example-graphical-snap/tree/22/Electron-quick-start to point at:
  https://demo.inductiveautomation.com/data/perspective/client/OnlineDemo/feature/reporting/examples
• build and install it
• start Mir, ubuntu-frame-osk and iot-example-graphical-snap
• find and focus the "Inteval" field

Expected:

• OSK pops up and stays up

Current:

• OSK pops up and quickly hides again

Even though the there's a lot of traffic, nothing in the client wayland requests suggests it should be hiding:

[4063403.674]  -> [email protected]()
[4063414.767]  -> [email protected]()
[4063418.886]  -> [email protected](wl_seat@10, wl_surface@21)
[4063418.907]  -> [email protected]_content_type(4, 3)
[4063419.005]  -> [email protected]_input_panel()
[4063419.051]  -> [email protected]_cursor_rectangle(1022, 354, 246, 236)
[4063419.086]  -> [email protected]_surrounding_text("1", 1, 1)
[4063419.253]  -> [email protected]_cursor_rectangle(1022, 354, 246, 236)
[4063419.343]  -> [email protected]_cursor_rectangle(1010, 513, 0, 20)
[4063419.378]  -> [email protected]()
[4063419.461]  -> [email protected]_input_panel()
[4063419.471]  -> [email protected]_cursor_rectangle(1010, 513, 0, 20)
[4063419.497]  -> [email protected]_cursor_rectangle(1010, 513, 0, 20)
[4063419.510]  -> [email protected]_surrounding_text("1", 0, 1)
[4063419.542]  -> [email protected]_cursor_rectangle(1010, 513, 0, 20)
[4063419.603] [email protected]()
[4063419.615] [email protected](wl_surface@21)
[4063419.633]  -> [email protected]_cursor_rectangle(1003, 513, 7, 20)
[4063421.949]  -> [email protected]_cursor_rectangle(1003, 513, 7, 20)
[4063422.271]  -> [email protected]_cursor_rectangle(1003, 513, 7, 20)
[4063519.588]  -> [email protected]_input_panel()
[4063519.610]  -> [email protected]_cursor_rectangle(1003, 513, 7, 20)
[4063622.079]  -> [email protected]_cursor_rectangle(1003, 513, 7, 20)
[4063622.377]  -> [email protected]_cursor_rectangle(1003, 513, 7, 20)

[tarek-y-ismail]

Looking at the client and server wayland debug logs, nothing seems out of the ordinary. I even sprinkled some debug printfs in places where I suspected things were off (text_input_unstable_v1), but again nothing seems incorrect. Running twice, activating a normal field, and one of the broken number fields the other time shows almost the exact same log, except for an extra text_input_unstable_v1.activate.

As a sanity check, I made the compositor treat all fields the same as the number field (by hardcoding the hint and purpose, see text_input_v1.set_content_type), all fields behave as expected (keyboard pops up on activation with the number pad) except the broken ones (same buggy behavior as before).

I haven't been able to get other keyboards to work (maliit, squeekboard, or wvkbd (this one is exclusive to wlroots anyway)), so it's not clear whether the issue is from the OSK or the client.

Checking the squeekboard issue list on Gitlab, I couldn't find any issues related to this behavior. Nor could I find anything related to electron other than us

[tarek-y-ismail]

The next logical step would be to build a local version of chromium to be able to debug it.

[AlanGriffiths]

From your earlier comment, you've established that there is nothing suspicious in the communication between the test client (which, incidentally, isn't chromium) and the compositor.

The next logical step is to check the communication between Mir and the OSK (zwp_input_method I guess). Either Mir is telling the OSK to dismiss, or the OSK is hiding without being told. In the first case, the bug is in Mir, in the second in Squeekboard.

The next logical step would be to build a local version of chromium to be able to debug it.

Unless you have established that chromium is not following the protocol and, therefore, know what to look for that seems unlikely to help.

[tarek-y-ismail]

you've established that there is nothing suspicious in the communication between the test client (which, incidentally, isn't chromium)

Isn't the example running on electron (which is pretty much chromium + other stuff)? Either way, now that I think about it more, I kinda agree that maybe another look at the Mir/keyboard side would a better start (faster than compiling electron, that's for sure :))

The next logical step is to check the communication between Mir and the OSK (zwp_input_method I guess).

From what I remember, I already went through the code for input_method and did some debug logging as a sanity check and found no suspicious things (other than an extra show call if I remember correctly). I haven't been able to get other keyboards running, so it may be an issue with squeekboard. That should be a good (re)starting point.

[AlanGriffiths]

From what I remember, I already went through the code for input_method and did some debug logging as a sanity check and found no suspicious things (other than an extra show call if I remember correctly). I haven't been able to get other keyboards running, so it may be an issue with squeekboard. That should be a good (re)starting point.

I meant check the WAYLAND_DEBUG on the OSK: See what message the OSK is getting. (The reference above is to an extra activate on the client side, not a show on the OSK side.)