After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 793249 - Compose option not properly set depending on layout order
Compose option not properly set depending on layout order
Status: RESOLVED OBSOLETE
Product: gnome-settings-daemon
Classification: Core
Component: keyboard
3.26.x
Other Linux
: Normal normal
: ---
Assigned To: Rui Matos
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2018-02-07 11:41 UTC by Jehan
Modified: 2019-03-20 11:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jehan 2018-02-07 11:41:50 UTC
Through the GNOME Tweak tool, I set a Compose key in place of CapsLock.
Looking in dconf, it seems a key was properly set up, so I am assuming the issue is not within GNOME Tweak tool:
org.gnome.desktop.input-sources xkb-options ['compose:caps']

The problem is that when I have the Japanese layout (not the Ibus one, I am talking about the XKB's "jp" layout), the CapsLock both works as Compose key and as Caps Lock!

Steps:

(1) Set 2 layouts in your "Input sources": "English (US)" first, "Japanese" second.
(2) Set 'compose:caps' in org.gnome.desktop.input-sources xkb-options (or just use GNOME Tweaks Tool, in the "Keyboard & Mouse" tab, there is a "Compose Key" option which does the work for you).
(3) Make sure you are set for "English (US)" input (not Japanese)
(4) Hold CapsLock + o + e (anywhere where you can type).

Expected result: the light on the CapsLock key must not switch on, Capitalization of letter must not be locked for subsequent letters, and "œ" must be outputted.

Actual result: the light on the CapsLock key goes on, Capitalization of letter is locked for subsequent letters, and "Œ" is outputted.
So "compose:caps" did not just override the CapsLock behavior but instead added the compose behavior (and the key does both at once, which is weird).

More tests:
- Keeping the same order, it seems CapsLock key works only as CapsLock (not compose) when set on the Japanese layout which is double-broken.
- If you invert the order of layouts: "Japanese" first then "English (US)" second, then CapsLock key works as it should (as Compose only), whatever the layout currently set.
- If you remove "Japanese" from the list of layouts, then CapsLock also works as expected (i.e. as Compose).

So it would seem that Japanese is breaking other layout (my steps use "English (US)" but this bug is actually reproduced with a wide range of layouts, actually any one I tested so far) when it is *after* them, not *before*.

This could also be a bug in XKB, but if you run the following as command line:

> setxkbmap -layout us -option compose:caps

… then CapsLock works only as Compose key, as expected, even with Japanese in the end of the list. So direct setting through CLI works just fine.

I have thought that maybe the problem is in gnome-shell, but since I could also reproduce it in GNOME Flashback, I was told that was likely not the case: https://gitlab.gnome.org/GNOME/gnome-shell/issues/14

So I was told that maybe gnome-settings-daemon does not properly set the option. Also note that this used to work fine until Fedora 25, and stopped in Fedora 26 and higher (in case it helps with version numbers of packages in the input stack). I always had the same bunch of layouts in my list in the same order.

If the bug is not in gnome-settings-daemon, I would appreciate some help to know where to report this weird bug.
Comment 1 GNOME Infrastructure Team 2019-03-20 11:53:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/issues/384.