-
Notifications
You must be signed in to change notification settings - Fork 103
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
OSK hides a half second after popping up on some input fields with zwp_text_input_v1
(Electron)
#3580
Comments
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 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 |
The next logical step would be to build a local version of chromium to be able to debug it. |
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 (
Unless you have established that chromium is not following the protocol and, therefore, know what to look for that seems unlikely to help. |
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 :))
From what I remember, I already went through the code for |
I meant check the |
@Saviq Issue still occurs with latest squeekboard/ubuntu-frame-osk and no workaround applied. The logs look a bit different though. logThe first few "Gtk-CRITICAL ... new configuration without asking" blocks are printed when focusing on normal text fields, the last two or so are printed when focusing on the "Interval" field.
|
Steps:
https://demo.inductiveautomation.com/data/perspective/client/OnlineDemo/feature/reporting/examples
iot-example-graphical-snap
Expected:
Current:
Even though the there's a lot of traffic, nothing in the client wayland requests suggests it should be hiding:
The text was updated successfully, but these errors were encountered: