incorrect handling of cursor keys with custom keyboard layout

[cheater]

Hi,
when you press shift + cursor key (be it the arrows, pg up/dn or home/end) text should get selected.

I have made a layout in which the cursor keys are only available via alt-gr + hjkl (for the arrows) and yuio (for home, pgdn, pgup, end respectively). When I press those while holding shift the cursor moves, but text doesn't get selected. This is not an issue in e.g. Firefox.

I am assuming the issue happens in upstream as well.

You can reproduce by installing this layout:
https://bitbucket.org/cheater/us_split_cherry_kw6000

Download it, run sudo python install.py, and then select it in the keyboard preferences: go to the tab "by language", select "English", and scroll all the way down to USA Split (Cherry KW 6000/etc etc)

Then, open pluma, and add several lines of text.

Then, select this layout, and press the Menu key (which is mapped to Alt Gr/Level 3) and hjkl to move around like in vim. Note: hjkl are in fact mapped to kl;'. So to move left you press Menu+k, to go right you press Menu+', to go down you press Menu+l, to go up you press Menu+k.

Once you can confidently move the cursor try moving it while holding shift. Text SHOULD become selected, but doesn't.

For an example of where it works, open Firefox and use any text entry control. For example the address bar, or this bug report form. Might work in Chrome too, but I haven't checked.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/4318493-incorrect-handling-of-cursor-keys-with-custom-keyboard-layout?utm_campaign=plugin&utm_content=tracker%2F1179776&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1179776&utm_medium=issues&utm_source=github).

[cheater]

BTW, please also try with home/pgdn/pgup/end, which are mapped to AltGr+yuio (so on a normal us keyboard with this layout you'd press Menu+iop[)

[raveit65]

Does this issue still exists with pluma-1-6.x

[cheater]

Nope, it's fixed. Great! What's the relevant commit?

[raveit65]

"mark as can be closed"

[cheater]

I would, but it's not really fixed until we know what's fixed it. Otherwise a future change might unfix it. Documenting this here will help secure the durability of this fix.

[cheater]

upon more testing, there still is an issue. I misunderstood my original bug report. Selecting text still does not work: if you press shift, and use a key combination which results in cursor movement, text does not get selected.

I said the bug was fixed because I misread my bug report, I thought the bug report was that the cursors didn't work at all. They do, however, you just can't select text with shift.

[flexiondotorg]

I have tested this with MATE 1.6 on Arch Linux and can't reproduce the fault you describe.

I can select text using SHIFT+CURSORS, SHIFT+PGUP/PGDN and SHIFT+HOME/END. I can also cut with SHIFT+DEL and paste with SHIFT+INSERT.

[cheater]

Hi flexiondotorg,
it's likely because you've got a layout which has dedicated cursor keys, in which case what you're saying works perfectly for me, too.
In the layout I'm using, the cursor keys are typed by pressing the "ISO Level 3 Shift" key and using HJKL or YUIO.

So to select text to the right one would press and hold Shift, press and hold the ISO Level 3 Shift, and then hold the L key.

[AlexDaniel]

Confirming. Shift selection does not work with custom arrow keys. FWIW, ctrl+arrows works fine.

I don't use pluma myself, but I was searching for other victims of improper keyboard handling.

See https://superuser.com/a/1000320/521612.

@cheater any chance you can contact me so that we can coordinate our efforts? For example, have you already submitted a bug report for Chromium (or any software which is using chromium indirectly e.g. through electron)? Or do you know any other software that has the same bug? Generally, any modern project using latest GTK or QT should work fine by default, and personally I haven't experienced the problem for a long time now. But now that electron is becoming more popular, I have to deal with garbage keyboard handling in chromium, so I'm really interested in getting it fixed.

[AlexDaniel]

Oh. I just noticed something. Arrow keys from neo(de) layout work fine in Pluma. In Neo layout, these keys are on Level5 (and Level6 when you're shift selecting), and it seems that there is some hack in place (in the layout itself) to make it work.

If somebody could figure out the difference in what pluma sees when you use arrows with neo(de) layout vs the layout in OP, then we're golden. Either it will show what changes should be done to the layout to make it work everywhere, or we'll apply a similar fix in every software that does not work.

[AlexDaniel]

OK, so Neo layout is working because it does some magic using EIGHT_LEVEL_LEVEL_FIVE_LOCK.

You can actually try putting your arrow keys on level five, which will need this:

    key.type[Group1] = "EIGHT_LEVEL_LEVEL_FIVE_LOCK";

And also something to do the switching, e.g. include "level5(lsgt_switch)".

I tried it and it does work to some extent. For some reason emacs didn't like this setup, but pluma and chromium were quite happy about it (neo layout does not work for me in emacs too).

@bluetech, any chance you can comment on this? I'm sure it will be super helpful. Generally, if I have something like this in my layout:

key <AC02> { [ o, O, Left, Left ] };

Am I right to expect that any software is supposed to understand it correctly, including Shift+Left and other combinations? And if so, how can I get this point across to chromium devs, because I have a feeling that “I made a custom keyboard layout and it doesn't work” is not going to fly.

[cheater]

@AlexDaniel sure, in fact i haven't touched my layout in ages and would love to clean it up if you think you can help.

[bluetech]

@AlexDaniel I would be happy to try and help, but I don't quite get follow what the problem is. Could you summarize for me? The following would be helpful: the keymap being used; expected behavior; actual behavior.

[AlexDaniel]

Hey @bluetech.

• Expected behavior: Pressing shift + cursor keys should select text
• Actual behavior: The cursor moves, but no text is selected (just like if shift was not pressed).

When I say “cursor keys”, I mean those keys that are defined in the layout to be cursor keys. For example:

    key <AD01> { [ q,  Q,  Escape,     Escape      ] };
    key <AD02> { [ w,  W,  Home,       Home        ] };
    key <AD03> { [ e,  E,  Up,         Up          ] };
    key <AD04> { [ r,  R,  End,        End         ] };
    key <AD05> { [ t,  T,  Tab,        Tab         ] };

    key <AC01> { [ a,  A,  Return,     Return      ] };
    key <AC02> { [ s,  S,  Left,       Left        ] };
    key <AC03> { [ d,  D,  Down,       Down        ] };
    key <AC04> { [ f,  F,  Right,      Right       ] };
    key <AC05> { [ g,  G,  BackSpace,  BackSpace   ] };

As you can see, Left Down Right Up Home End are all on 3rd and 4th levels, which can normally be accessed with AltGr key.

If you're wondering how many people actually use this, then you're right, there are probably just a few hundreds of us in the world (users of neo layout not counted because their workaround-ish layout works almost everywhere). That being said, up to date I know only two programs where shift selection does not work: pluma and chromium :) (the situation was much worse a few years ago when all QT apps sucked, but these times are long gone given that it is now fixed upstream).

Hey @bluetech, do you want to reproduce the issue on your computer? If so, here's what you can do:

1. Download this layout file: https://gist.github.com/AlexDaniel/0ba2044f3c36d06bd9e4e2211e3d13bb
2. Put it somewhere, let's say $HOME/.xkb
3. Run this command to switch to it: setxkbmap 'awesome' -option 'lv3:ralt_switch' -print | xkbcomp -I"$HOME/.xkb" - "$DISPLAY" (you may see some warnings and it's probably OK)
4. Press right alt (which is now set to AltGr) and while holding it try pressing E S D F keys (this should work just like if you were pressing dedicated arrow keys that you normally use). To reproduce the issue you'd have to hold AltGr and Shift at the same time.

FWIW, I assumed that you use QWERTY so the layout file above was based on it. That said, it's not exactly what I use, but it's exactly what is needed to reproduce the issue.

I hope this helps. Let me know if you need more info.

[bluetech]

Which toolkit does pluma use (gtk/qt/something else?).

If you don't mind testing a theory, try editing your cursor keys to look like this:

key <AD03> {                      
    type="THREE_LEVEL",
    symbols=[ e,  E,           Up]
};

And also (hack for testing) try adding the following line to the types/iso9995 in the xkb directory:

preserve[Shift+LevelThree] = Shift;

and see how the applications behave.

[AlexDaniel]

Oh, @bluetech. I didn't recognize you at first :) Hello! Thank you for taking a look.

Anyway, with both of the suggested changes shift selection starts working in Chromium. What does it tell you?

As for pluma, AltGr+Shift+[some key] starts typing the character (e.g. “e”).

Without the “preserve” change (with only the first suggested change) I see no difference in both pluma and chromium.

[AlexDaniel]

Also, Pluma seems to be using GTK, but I don't know the details.

[AlexDaniel]

Oh yeah, it's not just Pluma. THREE_LEVEL + preserve makes it work for chromium but breaks it for everything else.

[cheater]

I don't think i have reported it in chromium but it was a long time ago.

[bluetech]

Pluma seems to be using GTK

Right, I see in the configure.ac that it is using GTK3. GTK3 normally takes care of this stuff, so probably pluma does some of its own key processing? Does an editor like gedit behave as you expect?

What does it tell you?

I will need to explain some things.

First thing to explain is the concept of "type" in XKB. The "type" of a key group specifies the "shape" of key group (how a specific key behaves when you are in a specific layout). For example the THREE_LEVEL type is defined like this:

type "THREE_LEVEL" {
    modifiers = Shift+LevelThree;
    map[None] = Level1;
    map[Shift] = Level2;
    map[LevelThree] = Level3;
    map[Shift+LevelThree] = Level3;
    level_name[Level1] = "Base";
    level_name[Level2] = "Shift";
    level_name[Level3] = "Level3";
};

If a key group is attached this type, it means the key group will have 3 levels, named "Base", "Shift" and "Level3". It is affected only by the modifiers Shift and LevelThree (the lv3:ralt_switch option sets this modifier to right-alt). Other modifiers won't affect which level is chosen. The map directives say that when none of these modifiers are active, first level is chosen, when both Shift and LevelThree are active, level 3 is chosen, etc.

In the keymap symbols file, unless you explicitly specify e.g. type="THREE_LEVEL", a type is automatically chosen for you.

Next thing I need to explain is "consumed modifiers". If for example we use the THREE_LEVEL type, when we use the modifiers Shift and LevelThree, they affect the keysym that is produced. In this sense, they are already "consumed" by the keymap processing. If the application then does its own further key processing, e.g. key shortcut handling, it can check which modifiers were already consumed, and then decide to ignore them and not consume them again. Some applications can decide to not care about consumed modifiers or handle them differently. There are many cases where this stuff is important, I won't get into it, but I can explain if you want.

OK, so in the THREE_LEVEL type, we have this

map[Shift+LevelThree] = Level3;

so of course, if you type Shift+LevelThree+AC02, both modifiers are consumed, and are reported as such to the application. But in your case, when you type Shift+LevelThree+AC02, you didn't really mean to use this rule in the type, what you really meant was to use the map[LevelThree] = Level3; rule, and leave Shift as just an extra unrelated modifier. The type allows you to say that; by adding the

preserve[Shift+LevelThree] = Shift;

line, you are saying that in e.g. Shift+LevelThree+AC02, don't consume Shift, but "preserve" it.

THREE_LEVEL + preserve makes it work for chromium but breaks it for everything else.

How do these applications which break behave after this change?

[AlexDaniel]

Thank you so much for your time!

Does an editor like gedit behave as you expect?

OK, actually that's a very good question. The picture is really not that great now that I look at it. I guess the reason why I never noticed it before is that I normally don't work with text in programs like VLC, but I can still test it if I go to settings and play with some text fields. As for other text editors, it just happened that I never used them before.

• ✓ geany (GTK 2) – works
• ✗ pluma (GTK 3) – does not work
• ✗ gedit (GTK 3) – does not work
• ✗ leafpad (GTK 2) – does not work
• ✓ emacs (GTK 3?) – works
• ✗ spacefm (both gtk2 and gtk3 versions) – does not work
• ✓ firefox (≈GTK 2 ?) – works
• ✗ chromium (?) – does not work
• ✓ speedcrunch (Qt 5) – works
• ✓ qbittorrent (Qt 5) – works
• ✗ transmission (GTK 3) – does not work
• ✓ LibreOffice (?) – works
• ✓ VLC (?) – works
• ✗ GIMP (GTK 2) – does not work
• ✓ krita (Qt 5) – works
• ± inkscape (GTK 2) – depends. Works when shift-selecting text on the image, but does not work in any menu or edit field
• ✓ blender (GTK 2?) – works
• ✓ keepassx (Qt 4) – works
• ✗ gparted (GTK 2) – does not work

The only pattern I can see here is that everything using QT works just fine, and half of the GTK stuff does not. All these were tested without both of the proposed changes, should I do other tests?

How do these applications which break behave after this change?

As mentioned above, the letter from Level1 is being typed. So I press ralt+shift+e and I get letter “e”.

[bluetech]

I played with your layout a bit (+ making Shift preserved). My conclusion is that GTK3-Wayland regressed here in the handling of consumed modifiers. GTK2 works correctly under Xorg and XWayland. GTK3 works correctly under Xorg (I didn't try XWayland). GTK3 does not work correctly under Wayland.

Since pluma uses GTK3, I suggest filing a bug about this in the gnome bugzilla (gtk+ Wayland component).

The following API in xkbcommon might be of interest: https://github.com/xkbcommon/libxkbcommon/blob/8db924b87df7fdd40023b55a3ee55558d6fd841e/xkbcommon/xkbcommon.h#L1694

Feel free to cc me on the bug.

[AlexDaniel]

OK, some time has passed since my last reply. The reason is that I'm really confused. You say that both GTK3 and GTK2 should work fine with Xorg, and that GTK3-Wayland is the problem. But I'm not using wayland. The whole wayland problem may be there, but how is it related to me seeing the problem under xorg? 😕

[cheater]

Same here, no wayland

[AlexDaniel]

Today, all applications (including pluma and many in the list above marked with ✗) work correctly for me. I remember applying a small fix in my layout, but I think the fix was about using a custom button for Level3 (which fixed other issues), and I think that over the years apps started working properly because of upstream fixes.