Open AdamWill opened 2 months ago
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 gsettings get org.gnome.desktop.input-sources sources
command in your GNOME session and if the value includes ('ibus', 'typing-booster')
, I'd like to ask you to test your session without the typing-booster.
Maybe you could override it with the gsettings
command. E.g. gsettings set org.gnome.desktop.input-sources sources "[('xkb', 'us'), ('ibus', 'hangul')]"
in case you install ibus-hangul and run the GNOME session and ibus-daemon.
The configuration can be done with gnome-control-center keyboard
utility too.
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.
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: