glib2.0 2.75.3-3 breaks text input for Firefox & Chromium snaps if IBus is turned on

Wow.. This is "interesting". Compare this with bug #2007379, where we work around the problem which the now reversed upstream g-s-d commit tries to address. (I wasn't aware of this upstream move.)

im-config 0.55-1 is already in lunar-release. Can the fact that im-config now sets GTK_IM_MODULE=ibus be the reason why the upstream commit didn't work out well? Would that g-s-d commit possibly work for us with GTK_IM_MODULE unset? I think this is worth to investigate.

At least the g-s-d commit is the right idea.

As regards the recent im-config change, I suppose it's motivated in both jammy and Debian 12. (And also in lunar unless we figure out how to avoid the regression you describe in this bug.)

Btw, im-config 0.55-1 is not in Debian testing yet, which might be the reason why you didn't see the issue there.

I built g-s-d in a PPA with the revert reverted:

https://launchpad.net/~gunnarhj/+archive/ubuntu/gnome-settings-daemon/+packages

On wayland I see no difference; everything works as expected. Also with a fresh lunar install in VirtualBox.

But my observations on Xorg with my regular install was a bit surprising. With im-config 0.55-1 present (i.e. GTK_IM_MODULE set to "ibus"), I do not notice any problems with the upstream g-s-d commit. I can type in the Firefox address bar — also in Chinese. But if I revert the latest im-config change, so nothing sets GTK_IM_MODULE, I can't even log in to "Ubuntu on Xorg".

So my first theory seems to be very wrong, and rather the opposite is true: The upstream g-s-d commit works for me *only* if also GTK_IM_MODULE is set to "ibus".

As regards the VirtualBox fresh install: Couldn't log in to x11 now either. (And this time I used the version of VirtualBox from lunar-release.)

Please disregard my "couldn't login" talk in the previous comment. I was confused. Not the first time in history, and not the last.

So:

The version in my PPA (including that upstream g-s-d commit) works fine for me on my regular lunar install. I can type in the address bar in both the Firefox and the Chromium snap. It also lets me revert the latest im-config change, and it still works on x11 without the issue described in bug #2007379. As expected, in other words.

(My VirtualBox "can't login to x11" issue is still there, though. But that's another story.)

Hmm.. Suddenly I could no longer type in the address bar of the Firefox snap. But I think the culprit is glib2.0 2.75.3-3, which I installed from -proposed yesterday in order to test build g-c-c from ubuntu/master. After having downgraded glib2.0 to 2.74.5-1 the issue is no longer present.

With glib2.0 2.75.3-3 installed and when starting the Firefox snap from terminal I see these warning messages:

[Parent 3792, Main Thread] WARNING: Unable to connect to ibus: Could not connect: Permission denied: 'glib warning', file /build/firefox/parts/firefox/build/toolkit/xre/nsSigHandlers.cpp:167

(firefox:3792): IBUS-WARNING **: 15:23:11.814: Unable to connect to ibus: Could not connect: Permission denied

FTR the issue is present on both wayland and x11.

Want to mention that the issue is not present with glib2.0 2.75.3-3 if fcitx5 is used instead of ibus. :/

ibus in lunar-release was built against glib2.0 2.74.5-1. I tried a no-change rebuild of ibus against glib2.0 2.75.3-3, but it didn't help.

(Such a rebuild may still be motivated later.)

@Jeremy: I figured out the nature of the issue you originally reported in this bug. With this combo:

$ dpkg-query -W libglib2.0-0 gnome-settings-daemon
gnome-settings-daemon 44~beta-1ubuntu1
libglib2.0-0:amd64 2.75.3-3

and as long as no IBus IM has been added to the list of input sources, you can successfully run the Firefox snap in a wayland session. I.e. with that upstream gnome-settings-daemon commit reverted.

If you had tried an x11 session, you'd have found that the reversal didn't help (because of im-config 0.55-1).

And if you had added some IBus IM (and re-logged in), you'd likewise have found that the reversal didn't help.

What does help in all cases ATM is to downgrade the glib2.0 packages to 2.74. So somehow the snaps need to be able to talk with ibus also when glib2.0 2.75 is present.

Is desktop working on this / going to?

Yes, Desktop will take responsibility for this issue.

Gunnar, can you add a test case to the bug description?

I don't know how to reproduce this issue with a new Ubuntu 23.04 install (using American English).

By the way, the issue still exists with glib 2.75.4-1 (currently in Debian Experimental and not in Ubuntu yet).

I think last time we had problems like this it was due to changes in the location of the socket for ibus's private D-Bus bus. Looking into the glib diffs for clues.

This seems like the most likely culprit:

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3005

This basically means that code that would have created an abstract namespace socket in glib 2.74.x now creates a regular unix domain socket in 2.75.x. We have AppArmor rules in snapd's desktop-legacy interface granting access to the abstract namespace socket in $XDG_CACHE_HOME, but nothing for the equivalent regular socket:

https://github.com/snapcore/snapd/blob/d5f47ca71fcd8a884072e75391a7e55d9ec9d145/interfaces/builtin/desktop_legacy.go#L142-L149

I still need to verify this is the actual cause, but if so it should be relatively simple to update snapd's AppArmor rules to allow access to this socket.

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(1678248386.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.

I've created https://github.com/snapcore/snapd/pull/12627 as a proposed fix for the issue.

@Michael: Any chance you can make a new bug fix release of snapd soon? This issue blocks quite a few packages from migrating to lunar-release.

I talked to Michael and did an upload with the patch cherrypicked

Great, Seb. Guess we'd better remove the block-proposed tag then.

I'm going to add the block-proposed back until snapd migrates and the fix is confirmed to work, we don't want to risk migrating glib while the snapd fix is still in proposed

Removing block-proposed again after a short IRC talk with Sebastien. We don't want to prevent snapd from migrating.

Added the block-proposed tag to bug #2004241 instead.

This bug was fixed in the package snapd - 2.58.3+23.04ubuntu1

---------------
snapd (2.58.3+23.04ubuntu1) lunar; urgency=medium

  * Cherry pick a fix from James Henstridge to grant access to new ibus
    socket location in desktop-legacy,fixes text input isn't working anymore
    in the firefox snap with glib 2.75 (lp: #2008279)

 -- Sebastien Bacher <email address hidden> Wed, 08 Mar 2023 13:50:10 +0100