Cannot use "copy" keys (symbols, emoji) in Electron

[neta540]

My layout has some keys like emojis and symbols using the COPY method, as defined in:

wvkbd/keyboard.c

Line 487 in ca53099

case Copy:

Each time the key is pressed, Electron apps do not receive the symbol and instead open a context menu as if I pressed mouse right click. This happens under Wayland only, in apps like Visual Studio Code (in Editor window only, terminal window seems fine) and Discord.

Using Visual Studio Code screencast option, to see which keys are being pressed, it shows "ContextMenu" key presses each time I try to input a key made from COPY. This makes wvkbd with Electron apps under Wayland unusable to me.

Any fix?

[proycon]

On Tue Nov 26, 2024 at 6:32 PM CET, N wrote: My layout has some keys like emojis and symbols using the COPY method, as defined in: https://github.com/jjsullivan5196/wvkbd/blob/ca53099c9de78574ac6bba6f31c72d27e1f59fca/keyboard.c#L487 Each time the key is pressed, Electron apps do not receive the symbol and instead open a context menu as if I pressed mouse right click. This happens under Wayland only, in apps like Visual Studio Code (in Editor window only, terminal window seems fine) and Discord. Using Visual Studio Code screencast option, to see which keys are being pressed, it shows "ContextMenu" key presses each time I try to input a key made from COPY.

That's correct. In order to pass arbitrary key codes, we temporarily change one keymap entry for one uncommon key (currently keycode 127) which is rarelty used and then press that key. So they keymap changes slightly every time you press another COPY key.

This makes wvkbd with Electron apps under Wayland unusable to me. Any fix?

I just tried in one electron (v33) app (element) and there I couldn't reproduce the issue (on riverwm). Maybe the apps you mentioned directly handle that keycode? What you could try, is see if using another uncommon keycode solves the problem. For example, replace 127 in keyboard.c:301 and keyboard.c:496 with 123, 124 or 240 (KEY_UNKNOWN). If another 'copy' keycode is safer to use than the one we currently use then we can switch to that. What sometimes also might be an issue is if another IME is in the way (such as fcitx), but I don't think that's the case in your situation.

[neta540]

I tried changing the keycode to 123, 124 and 240 per the suggestion. Once changed, the context menu does not appear, but the expected symbols/emojis are not printed either, neither in Electron nor in other apps.

Out of curiosity, I changed the keycode to KEY_0, only because it's a printable character, When set to KEY_0, the 0 character is printed. Seems like 127 KEY_COMPOSE is required?

I am using Hyprland as compositor:

.config/hypr/hyprland.conf

...
input {
    kb_layout = us
    kb_variant =
    kb_model =
    kb_options =
    kb_rules =

    follow_mouse = 1

    sensitivity = 0 # -1.0 - 1.0, 0 means no modification.
    scroll_method = edge

    touchpad {
        natural_scroll = true
    }
}
...

[neta540]

I can confirm that on riverwm I cannot reproduce the issue either. But I tested that on niri compositor as well, and the issue appears there too.

[proycon]

On Tue Nov 26, 2024 at 9:36 PM CET, N wrote: I tried changing the keycode to `123`, `124` and `240` per the suggestion. Once changed, the context menu does not appear, but the expected symbols/emojis are not printed either, neither in Electron nor in other apps.

Ah sorry, I forgot one essential part! The code has to be changed in the keymap as well. In keymap.mobintl.h you see the current definition on line 7210 . There you see two values that will be substituted at-run time (these two values may only occur once in the whole keymap). If you use another key instead of COMP then these values should be moved to that other key. Try swapping <COMP> and <HNGL> (a few lines above) and then use code 122 instead of 127. Let's see if that works.

Out of curiosity, I changed the keycode to `KEY_0,` only because it's a printable character, When set to `KEY_0`, the `0` character is printed. Seems like 127 `KEY_COMPOSE` is required?

Right, that too is because the keymap wasn't changed.

[proycon]

On Thu Nov 28, 2024 at 12:04 AM CET, N wrote: I can confirm that on `riverwm` I cannot reproduce the issue either. But I tested that on `niri` compositor as well, and the issue appears there too.

You can get even more debugging out of it by running wvkbd with -D and setting environment variable WAYLAND_DEBUG=1 (it will be very verbose from both), that might also help identify differences between compositors. But we best try what I mentioned earlier first.

[neta540]

This looks like one step closer to a fix. Using HNGL instead of COMP now allows me to insert symbols. I can still write both emojis and symbols into non electron apps, using key code 122.

But, emojis are not displayed correctly in Electron when typed through the virtual keyboard. At first I thought it might be a font or a fontconfig issue, but when I paste into Visual Studio Code emojis that were copied from other apps, they display correctly.

[neta540]

first line shows emojis inserted through the virtual keyboard, second line is emojis copied and pasted from another application

藍﫥沈﫡
😳😩🥴🥴😩🥴😩🥹🥱🥹🥱

[proycon]

On Fri Nov 29, 2024 at 3:02 AM CET, N wrote: first line shows emojis inserted through the virtual keyboard, second line is emojis copied and pasted from another application ``` 藍﫥沈﫡 😳😩🥴🥴😩🥴😩🥹🥱🥹🥱 ```

Hmm, the top row is in a completely different range. It's as if these higher unicode points don't make it through correctly. I wonder if the difference is exactly 0x10000 ... Typing lower-range characters (like ç,ş,ğ does work fine I assume?) This again occurs only in Electron apps on Hyprland right? Normal wayland applications work fine? I wonder if chromium works fine too (since electron builds on that). In any case, it seems that this is not as much an issue in wvkbd itself (aside from maybe using another key instead of <COMP>), but more in the combination Hyprland + electron, and I don't really understand why. So I don't really have a good solution unfortunately. You could see if WAYLAND_DEBUG=1 provides some more insight.

[neta540]

• My observation is that 0x10000 is omitted, that is the difference between the failing emojis and the output characters. Lower range characters work fine.

• I tested it with a few applications on wayland and they are fine, I can't see this behavior anywhere else but Electron, but maybe I miss some test cases.

• Chromium works fine.