Okay. In a clean Lunar VM with glib 2.75.3 installed and ibus enabled as described in the bug description, I could reproduce the input problems in Firefox. I saw the following AppArmor denial in the dmesg logs:
I edited /var/lib/snapd/apparmor/profiles/snap.firefox.firefox and added the following rule:
@{HOME}/.cache/ibus/dbus-* rw,
After reloading the policy with "apparmor_parser -r .../snap.firefox.firefox", keyboard input worked again. So that confirms my guess about the cause of the problem. This is something we can fix via a snapd update.
Longer term, we should get these snaps using ibus's portal interface, which is both more secure (i.e. suitable to allow in the desktop interface) and should be immune to future changes of this type.
Okay. In a clean Lunar VM with glib 2.75.3 installed and ibus enabled as described in the bug description, I could reproduce the input problems in Firefox. I saw the following AppArmor denial in the dmesg logs:
[ +0.343553] audit: type=1400 audit(167824838 6.012:62) : apparmor="DENIED" operation="connect" profile= "snap.firefox. firefox" name="/ home/james/ .cache/ ibus/dbus- THbBfRNt" pid=2398 comm="pool-firefox" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
I edited /var/lib/ snapd/apparmor/ profiles/ snap.firefox. firefox and added the following rule:
@{HOME} /.cache/ ibus/dbus- * rw,
After reloading the policy with "apparmor_parser -r .../snap. firefox. firefox" , keyboard input worked again. So that confirms my guess about the cause of the problem. This is something we can fix via a snapd update.
Longer term, we should get these snaps using ibus's portal interface, which is both more secure (i.e. suitable to allow in the desktop interface) and should be immune to future changes of this type.