Typing into text boxes sometimes fails, apparently due to ibus interactions #548
Comments
|
CC @fujiwarat |
|
Ooh! I just randomly reproduced this manually for the first time, when I was trying to do something completely different. Happened on a Fedora 39 Silverblue image openQA built to test https://bodhi.fedoraproject.org/updates/FEDORA-2024-4afd3d38ae . Looking at the openQA test history this does indeed affect F39 updates there too. |
|
oooh. so, the manual reproduction makes this seem worse, because it's consistent. no matter how many times I reboot the affected install, the bug happens on every boot. I think maybe the broken state gets baked in at install time somehow? I guess the good part is this should make reproducing easier. I'll take a copy of the affected disk image, and it should be possible for anyone to reproduce by booting that image. |
|
So this could be a "build time" issue linked to how rpm-ostree does the compose. 🤔 |
|
Ugh. Crap. After completely powering down the VM and fiddling with the qcow2 file a bit (it turned out to be super large because of snapshots and stuff), I booted the VM again, and this time didn't hit the bug :( So either somehow cleaning up the snapshots fixed it(?!) or it only persisted as long as I was warm booting the system, not completely powering it off. Or I just got incredibly lucky to hit it four times in a row, I guess. |
|
I think one possible reason. Does your problem happen when you don't use ibus-typing-booster? |
|
hum, well, given how early the problem happens turning it off would be hard. I could possibly tweak the test that builds a Silverblue ostree and installer for updates to leave ibus-typing-booster out, though, and see if that makes the problem go away? I'll give it a shot. edit: to be clear, the affected tests do not intentionally enable or use an ibus-typing-booster layout, they are using perfectly normal 'us' layout input. but I assume you mean ibus-typing-booster may be somehow 'active' even without it being configured as an input method? |
|
OK, Strictly speaking, installing ibus-typing-booster is fine but I'd ask if your problem happens without ibus-typing-booster in the user configured engine list. You can check the current engine list with |
|
OK, I will check, but I'm pretty sure it won't be there. This is happening to a clean out-of-the-box install in English with nothing done to change the input configuration from just the 'us' keyboard layout. Also note the bug happens before we reach a logged-in desktop session at all, which makes it trickier to use gsettings (it happens either during gnome-initial-setup when it happens during first install, or at GDM when it happens after first install). |
|
@AdamWill Thank you for the test. My assumption was not correct but I have a plan to enhance to check the "FocusId" D-Bus property in Fedora 41 and will let me ask you to test the issue again if the issue is not fixed yet. |
The silverblue tests are flaky because of fedora-silverblue/issue-tracker#548 . The desktop_upgrade_encrypted test is flaky on Rawhide (so, when booting from F40 initially) since we switched to UEFI, not sure if it's because of UEFI somehow or just a timing coincidence. Am going to look into it, but for now this should save lots of manual restarting. Signed-off-by: Adam Williamson <awilliam@redhat.com>
Describe the bug
In openQA testing of Silverblue, sometimes when we boot a freshly-installed Silverblue system, we cannot type. On the initial install test, this will cause failure at the timezone screen in gnome-initial-setup, because we cannot type the name of the city. On tests of applications etc. that run on a disk image inherited from the initial install test, this causes failure to log in (because we cannot type the password). Interestingly, the initial keypress of enter to select the user does work, indicating there's something specific to text entry boxes about this, perhaps.
To Reproduce
Please describe the steps needed to reproduce the bug:
Expected behavior
Characters should be input and appear on screen (or dots, in the case of gdm password entry).
OS version:
Fedora 40 and Rawhide.
Additional context
If I grep the journal for ibus (case-insensitive), I see:
...and then a lot more occurrences of that last message (there seem to be two per keypress). On a Silverblue boot where typing does work, we see these messages:
This bug never happens on Workstation. On a Workstation boot I only see these messages - fewer again than even the working Silverblue case, indicating there's some difference there, but I don't fully know what:
The text was updated successfully, but these errors were encountered: