[SOLVED] Unresponsive Keyboard Input in Text Fields of Web Browsers

yorkz · 2024-03-28 20:03:42

Hello Arch Community,

I'm seeking advice on an issue I've encountered with my Arch Linux system post-upgrade (by issuing the "sudo pacman -Syu" command last night). The problem is quite specific: when using StumpWM as my window manager, keyboard input fails to work in any web browser (Brave, Firefox, and Microsoft Edge). This issue does not occur in KDE Plasma, where keyboard input in these browsers works perfectly fine.

It's worth noting that this issue is isolated to web browsers; other types of applications do not seem to be affected. Given the specificity to web browsers under StumpWM, I suspect it may be related to how StumpWM handles input events for these applications.

I appreciate any help or guidance you can offer on this matter.

Best,

Last edited by yorkz (2024-03-31 14:34:04)

quoin · 2024-03-30 12:15:45

Sorry if this is all obvious (I'm getting mixed messages from your writing style whether you're a newbie or a grizzled expert), but:

Have a look in `/var/log/pacman.log` for the day when it all went wrong. You should see lines like this:

... [ALPM] upgraded linux-lts (6.6.22-1 -> 6.6.23-1)

That's saying that package `linux-lts` got updated. Take a look at what packages got updated that day, and ask yourself which might be relevant (google the package names to get some idea what they do). You might want to post those log lines here so others might take a guess at the culprit.

Then you can try things like:
- downgrading packages
- searching logs for relevant (e.g. `journatctl` -- you use the `-S` and `-U` flags to limit the date/time range you look at, e.g. `journatctl -S today`, and learn how to use `less` and its `/` search command if you don't know that)
- looking at the arch package web pages for those projects -- maybe other people are commenting on the same issue?
- looking at the changelog / history files of the upstream projects for those packages (e.g. on github)
- searching the issue trackers for the upstream of those projects (e.g. on github)

gg88 · 2024-03-30 22:40:30

I just came to the a very similar bug. For me it is the emacs and alacritty can't accept any inputs from the keyboard after a system upgrade.

After running xev and xwininfo, it seems like when pressed keys, xev just didn't print keystroke events.

after running

sudo pacman -U libx11-1.8.7-1-x86_64.pkg.tar.zst libxaw-1.0.15-1-x86_64.pkg.tar.zst libxmu-1.1.4-1-x86_64.pkg.tar.zst libxkbcommon-x11-1.6.0-1-x86_64.pkg.tar.zst libxkbcommon-1.6.0-1-x86_64.pkg.tar.zst

I think I get things back to the normal.

Last edited by gg88 (2024-03-30 22:41:21)

seth · 2024-03-30 23:40:11

There's a bug in libx11 that causes this - and a couple of threads about it

yorkz · 2024-03-31 01:49:58

First off, thanks @quoin for your comment. While I'm fairly familiar with all the methods you mentioned, I appreciate your intent to help, especially considering the complex nature of this issue. Given that more than two hundred packages were upgraded, pinpointing the problem was not as straightforward as downgrading one or two packages. I should have provided more detail in my initial post, and I apologize for that oversight. Anyway, I've now gained a much better understanding of this issue.

- The input problem specifically affected text input fields in web browsers; however, keyboard shortcuts within the browsers were still functional.
- Terminating `ibus-daemon` temporarily resolved the issue, indicating a link between `ibus` and the input problems. However, `ibus` was not upgraded in the full system upgrade.
- The issue is a complex interaction between `ibus`, `firejail`, and the Arch Linux update rather than a singular fault in one of these components. The conflict arises when `ibus` is active and browsers are sandboxed with `firejail`, leading to unresponsive text fields.
- The problem extends beyond StumpWM, as it was also reproducible in KDE, clarifying that it's a system-wide issue rather than being specific to a window manager or desktop environment.
- Additionally, I observed that both ibus and fcitx also caused frequent unresponsiveness in Emacs, which was not running inside a Firejail sandbox. This may be similar to @gg88's problem, and further emphasizes the systemic nature of the issue.
- Thanks to @seth and @gg88, downgrading `libx11` from 1.8.8-2 to 1.8.7-1 successfully resolved the input issues with web browsers, as well as the issue with Emacs, suggesting that a recent update to this package was a contributing factor.

Thank you all for your assistance and engagement.

Last edited by yorkz (2024-03-31 14:39:41)

seth · 2024-03-31 07:28:52

"The factor"
https://gitlab.freedesktop.org/xorg/lib … issues/205

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

yorkz · 2024-03-31 14:45:07

Just updated the subject. Thanks @seth for the reminder.

Arch Linux

#1 2024-03-28 20:03:42

[SOLVED] Unresponsive Keyboard Input in Text Fields of Web Browsers

#2 2024-03-30 12:15:45

Re: [SOLVED] Unresponsive Keyboard Input in Text Fields of Web Browsers

#3 2024-03-30 22:40:30

Re: [SOLVED] Unresponsive Keyboard Input in Text Fields of Web Browsers

#4 2024-03-30 23:40:11

Re: [SOLVED] Unresponsive Keyboard Input in Text Fields of Web Browsers

#5 2024-03-31 01:49:58

Re: [SOLVED] Unresponsive Keyboard Input in Text Fields of Web Browsers

#6 2024-03-31 07:28:52

Re: [SOLVED] Unresponsive Keyboard Input in Text Fields of Web Browsers

#7 2024-03-31 14:45:07

Re: [SOLVED] Unresponsive Keyboard Input in Text Fields of Web Browsers

Board footer