Snaps don't respect .XCompose

Bug #1989475 reported by Nathan Teodosio
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
snapd (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

Reproduction recipe:

--->
snap install gedit
apt install gedit

#Set compose key as AltGr under Xorg.
setxkbmap -option 'compose:ralt'

printf '%s\n' '<Multi_key> <x> <f> : "∫"' >> ~/.XCompose

snap run gedit
#Type [AltGr] [x] [f]
#Expected: ∫ is written
#Actual: f is written

/bin/gedit
#Type [AltGr] [x] [f]
#Expected: ∫ is written
#Actual: ∫ is written
<---

The same final results are observed if the Xim input method is used, by setting "GTK_IM_MODULE=xim". Though you can see that, as expected, the input module does change to Xim, since the transient underline character no longer shows up when you press the compose key.

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

Fixing this would at least partially solve https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1309781 (though it was originally reported for a .deb).

Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Nathan, I'm not able to reproduce this. The deb and snap versions work the same for me: when I press the compose key, the cursor becomes an underscore, but after typing "x" and "f" no character is emitted.

I have GTK_IM_MODULE=ibus set in my environment, but setting it to xim does not change this behaviour (though it makes most of the gedit window transparent, which looks like a bug on its own).

Can you guide me a bit, since I'm not an expert in input methods?

Changed in snapd (Ubuntu):
status: New → Incomplete
Revision history for this message
Nathan Teodosio (nteodosio) wrote (last edit ):

Hey Alberto,

At least the deb should have behaved according to ~/.XCompose. I tested in Kinetic and Jammy and they do. But since the compose key page in the Wiki[1] says

> To create your own set of compose keys copy the file /usr/share/X11/locale/en_US.UTF-8/Compose to your home directory as .XCompose and edit this file.

perhaps my test case is incomplete. So can you please try

  cp /usr/share/X11/locale/en_US.UTF-8/Compose ~/.XCompose
  printf '%s\n' '<Multi_key> <x> <f> : "∫"' >> ~/.XCompose

Quoting from [2], the whole X11 input stack is a mess. I only mentioned Xim because I read that

> See the XIM section of ComposeKey for instructions on how to use the X Input Method to set up alternative compose sequences.

from [3] and that

> GTK does not use XIM by default and therefore does not follow ~/.XCompose keys. This can be fixed by forcing GTK to use XIM by adding export GTK_IM_MODULE=xim and/or export XMODIFIERS="@im=none" to ~/.xprofile.

and [4]

> However, GTK does not use XIM by default and therefore does not follow ~/.XCompose keys. This can be fixed by forcing GTK to use XIM by adding export GTK_IM_MODULE=xim and/or export XMODIFIERS="@im=none" to ~/.xprofile.

> I have GTK_IM_MODULE=ibus set in my environment, but setting it to xim does not change this behaviour

You should also see no more underscore cursor.

  /usr/lib/x86_64-linux-gnu/libgtk-3-0/gtk-query-immodules-3.0 | grep xim

does return you an entry?

[1]: https://help.ubuntu.com/community/ComposeKey#XIM
[2]: https://unix.stackexchange.com/questions/260601/understanding-setting-up-different-input-methods
[3]: https://help.ubuntu.com/community/GtkComposeTable
[4]: https://wiki.archlinux.org/title/Xorg/Keyboard_configuration#Key_combinations
[5]: https://docs.gtk.org/gtk3/running.html

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

For debugging:

  ibus exit
  ibus-daemon --xim --verbose

From https://github.com/ibus/ibus/issues/1876#issuecomment-327979888.

Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Nathan, copying the whole XCompose file before adding the other line helped!

But... believe it or not, it also works on the gedit snap here! :-)

For the record, my locale is:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=it_IT.UTF-8
LC_TIME=it_IT.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=it_IT.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=it_IT.UTF-8
LC_NAME=it_IT.UTF-8
LC_ADDRESS=it_IT.UTF-8
LC_TELEPHONE=it_IT.UTF-8
LC_MEASUREMENT=it_IT.UTF-8
LC_IDENTIFICATION=it_IT.UTF-8
LC_ALL=

What about yours? I wonder if this is locale-dependent. If you leave a "journalctl -f" command open in another window before running the snap, do you see some warnings or apparmor denials?

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

> Hi Nathan, copying the whole XCompose file before adding the other line helped!

Wow, great! I was 99% convinced it wouldn't.

My locale is

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=pt_BR.UTF-8
LC_NUMERIC=pt_BR.UTF-8
LC_TIME=pt_BR.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=pt_BR.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=pt_BR.UTF-8
LC_NAME=pt_BR.UTF-8
LC_ADDRESS=pt_BR.UTF-8
LC_TELEPHONE=pt_BR.UTF-8
LC_MEASUREMENT=pt_BR.UTF-8
LC_IDENTIFICATION=pt_BR.UTF-8
LC_ALL=

I do see Apparmor denials — I'm attaching the full log —, but to my eyes none seem related to the issue.

Revision history for this message
Nathan Teodosio (nteodosio) wrote :
Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Nathan, indeed, those AppArmor denials are not related (I get the same ones). I tried setting the locale environment to match yours, but the gedit snap is still working fine for me. I wonder if you have something in your environment that breaks the composition?

Can you please try running this, and see if it works?

    env -i DISPLAY=":0" GTK_IM_MODULE=ibus snap run gedit

Revision history for this message
Nathan Teodosio (nteodosio) wrote : Re: [Bug 1989475] Re: Snaps don't respect .XCompose

Nice!

In my usual X session (barely a "startx dwm"), Gedit doesn't start; I get

--->
$ env -i DISPLAY=":0" GTK_IM_MODULE=ibus snap run gedit
Authorization required, but no authorization protocol specified

(gedit:66264): Gtk-WARNING **: 11:35:56.047: cannot open display: :0
<---

But if I start an usual Ubuntu Gnome session via a display manager, that
command causes Gedit to open normally and the "xf" composition sequence
works. But then again, the compose sequence doesn't work with a bare
"snap run gedit".

A suspicious variable (IM_CONFIG_PHASE) is only set in Gnome. I will
follow that trail to see where I come out at.

But anyway, this really doesn't look like a snap confinement problem.

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

Just for the record: The error under Dwm was caused by the lack of XAUTHORITY. Gnome must have some way around it.

--->
$ env -i DISPLAY=":0" GTK_IM_MODULE=ibus snap run gedit
Authorization required, but no authorization protocol specified

(gedit:66264): Gtk-WARNING **: 11:35:56.047: cannot open display: :0

$ env -i DISPLAY=":0" GTK_IM_MODULE=ibus XAUTHORITY="$XAUTHORITY" snap run gedit
[Gedit opens, but it's weird, but xf compose sequence doesn't work]
<---

Revision history for this message
Nathan Teodosio (nteodosio) wrote : Testing on Qt

Since GTK gave me enough headache already :), I tried a Qt program to
see what happened. Krop 0.6.0, both as a snap and a deb.

With the snap, no compose sequence works. [AltGr] [´] [e] results in
nothing instead of é.

With the deb, all compose sequence works, be it [AltGr] [´] [e] > é or
also my user defined one [AltGr] [x] [f] > ∫.

I still see nothing relevant in Journalctl, but the stderr does clearly say

   "Qt Warning: Compose file:
\"/usr/share/X11/locale/en_US.UTF-8/Compose\" can't be found"

Although that file does exist

   $ ls /usr/share/X11/locale/en_US.UTF-8/Compose
   -rw-r--r-- 1 root root 520K ago 4 03:21
/usr/share/X11/locale/en_US.UTF-8/Compose

I believe this is evidence this is snap caused, at least in this case.

Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Nathan, I tried the krop snap and it works for me.

I also think that this is snap-related, but maybe it's not due to the confinement by rather to some environment variable. I cannot exclude that the snaps themselves might be setting or clearing some variables in their startup script: see /snap/krop/current/snap/command-chain/desktop-launch for an example. It's very likely that something in these script is messing up with your environment.

I'll ask the Ubuntu Desktop team to have a look at this issue.

Revision history for this message
Nathan Teodosio (nteodosio) wrote : Gedit and Krop on Jammy VM

I now tested in a Jammy virtual machine (stock Ubuntu). The locale is
en_US.UTF-8.

Still no XCompose for me in snap.

--->
Package,LCompose,XCompose,Underscore
/bin/krop,1,1,1
snap run krop,1,0,0
/bin/gedit,1,1,1
snap run gedit,1,0,1

Key
LCompose: 1 if /usr/share/X11/locale/en_US.UTF-8/Compose works.
XCompose: 1 if ~/.XCompose works.
Underscore: 1 if hitting compose key turns the cursor into underscore.
<---

I'll see if I can find something off in desktop-launch.

Revision history for this message
Nathan Teodosio (nteodosio) wrote : Solved!

Ibus is looking for the file in $HOME:

https://github.com/ibus/ibus/blob/main/src/ibusenginesimple.c#L1475

Now, what is $HOME in each of the snap?

--->
$ snap run --shell krop
$ env grep -w HOME
HOME=/home/nteodosio/snap/krop/common

$ snap run --shell gedit
$ env grep -w HOME
$ HOME=/home/nteodosio/snap/gedit/653
<---

After moving .XCompose to those corresponding snap HOMEs, my composition
works.

Also worked for Firefox and Chromium!

Changed in snapd (Ubuntu):
assignee: nobody → Nathan Teodosio (nteodosio)
importance: Undecided → Low
Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Nathan, it's great that you find a solution! :-)

However, this still does not explain why it was working for me without the need to copy those files. Now, for the record, I don't know what happened, but neither the deb nor the snap work: they are not reading .XCompose at all!

Anyway, please don't assign the bug to you, unless you plan to work on it. I'll reset it to "unassigned", but if I misunderstood and you indeed intend to provide a solution so that it works out of the box, well, you are more than welcome :-)

Changed in snapd (Ubuntu):
assignee: Nathan Teodosio (nteodosio) → nobody
Revision history for this message
Nathan Teodosio (nteodosio) wrote : Re: [Bug 1989475] Re: Snaps don't respect .XCompose

Hi Alberto,

> However, this still does not explain why it was working for me without
> the need to copy those files.

Are you sure it was reading ~/.XCompose? Remember that the only
difference between ~/.XCompose and the locale compose
(/usr/share/X11/.../Compose) was the single line that mapped
[Compose][x][f] to ∫. That was the only map that would tell you whether
~/.XCompose worked.

Since this is a key piece of information, can you please confirm whether
you previous success reports included [Compose][x][f]?

 > Now, for the record, I don't know what happened, but neither the deb
 > nor the snap work: they are not reading .XCompose at all!

The plot thickens!

> Anyway, please don't assign the bug to you, unless you plan to work on
> it. I'll reset it to "unassigned", but if I misunderstood and you indeed
> intend to provide a solution so that it works out of the box, well, you
> are more than welcome :-)

Yes, I'd like to give it a go. :)

Changed in snapd (Ubuntu):
assignee: nobody → Nathan Teodosio (nteodosio)
Revision history for this message
Alberto Mardegan (mardy) wrote :

Hi Nathan, indeed the plot thickens! Now it's working again. I confirm I do have compose working for x + f, both in the snap and in the deb.

The snap indeed attempts to read /home/mardy/snap/gedit/653/.XCompose, but the file is not there (as expected, since I never copied it there).

And now the funny part. I edited ~/.XCompose and changed the "∫" into a "w". Restarted gedit, it still transforms the compose sequence into a "∫". Both deb and snap. I moved the modified .XCompose into the snap dir /home/mardy/snap/gedit/653/.XCompose, but it still prints "∫".

[After some more debugging]

I think I got it: ~/.XCompose is also read by the ibus service which is started with my session, and that that is the component responsible for doing the composition. I probably had the ~/.XCompose file left over from yesterday (I forgot to delete it) when I logged in today, so the composition was working. Now I ran "ibus restart" from a terminal, and x+f prints "w", as expected. And after deleting the ~/.XCompose file and running "ibus restart" again, x+f results in no character being added.

So, my guess is that the input library in the client (gedit) checks if ibus is running, and if it is, it delegates composition to it. So I guess that in your system you don't have ibus running?

Here I have:

===========
$ ps -fe | grep ibus
mardy 5686 1 0 07:21 ? 00:00:05 /usr/bin/ibus-daemon --daemonize --xim
mardy 5698 5686 0 07:21 ? 00:00:00 /usr/libexec/ibus-dconf
mardy 5699 5686 0 07:21 ? 00:00:01 /usr/libexec/ibus-ui-gtk3
mardy 5700 5686 0 07:21 ? 00:00:01 /usr/libexec/ibus-extension-gtk3
mardy 5702 1 0 07:21 ? 00:00:00 /usr/libexec/ibus-x11 --kill-daemon
mardy 5705 5282 0 07:21 ? 00:00:00 /usr/libexec/ibus-portal
mardy 5898 5686 0 07:21 ? 00:00:01 /usr/libexec/ibus-engine-simple
===========

Revision history for this message
Nathan Teodosio (nteodosio) wrote :

Great investigation! I would then conclude this:

- If Gedit delegates to Ibus, it doesn't matter if snap or deb, because Ibus can read .XCompose.
- If Gedit doesn't delegate to Ibus and instead uses GTK internal module, then the snap will fail to read .XCompose.

Now, I've just verified that [x][f] works under Wayland (in all my previous comments I was on Xorg), regardless of deb or snap.

> So I guess that in your system you don't have ibus running?

I do! Curious thing is the process list for Xorg is

--->
sh -c /usr/bin/ibus-daemon --panel disable $([ "$XDG_SESSION_TYPE" = "x11" ] && echo "--xim")
/usr/bin/ibus-daemon --panel disable --xim
/usr/libexec/ibus-engine-simple
/usr/libexec/ibus-extension-gtk3
/usr/libexec/ibus-memconf
/usr/libexec/ibus-portal
/usr/libexec/ibus-x11 --kill-daemon
<---

While for Wayland:

--->
sh -c /usr/bin/ibus-daemon --panel disable $([ "$XDG_SESSION_TYPE" = "x11" ] && echo "--xim")
/usr/bin/ibus-daemon --panel disable
/usr/libexec/ibus-engine-simple
/usr/libexec/ibus-extension-gtk3
/usr/libexec/ibus-memconf
/usr/libexec/ibus-portal
/usr/libexec/ibus-x11
<---

So the drop of "--xim" is the only relevant difference between the two.

Revision history for this message
Nathan Teodosio (nteodosio) wrote :
Changed in snapd (Ubuntu):
status: Incomplete → Confirmed
assignee: Nathan Teodosio (nteodosio) → nobody
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.