When bemoji inserts emoji into element-desktop, different characters appear

[Fethbita]

When I use bemoji with fuzzel with sway as follows:

bindsym $mod+period exec BEMOJI_PICKER_CMD="fuzzel -d" bemoji -n -t

and select an emoji on element-desktop, different characters appear. For example, 藍凉梁 appear when 👍🤣🍀🥹🥺 are typed. Not sure what causes the issue or if it is an element-desktop issue instead of bemoji.

[marty-oehme]

Interesting, perhaps the font used by element does not make use of the same unicode icons?

To begin figuring out where the issue lies you could manually go to the ~/.local/share/bemoji/emojis.txt file and copy one or multiple of the emoji there. Then paste them into element also manually and see if they show up correctly.

If they do, it is probably an error on bemoji's end, if they still don't show up correctly it would probably be something in element.

[nicobonada]

I have the same issue when using the vivaldi browser, but only when using bemoji -t.

It seems to be an issue with/related to wtype.

[marty-oehme]

Unfortunately I can't really reproduce the issue in element-desktop. When I use bemoji -t it correctly outputs the emoji into the element message field. I haven't tried on vivaldi.

I think there are 2 possibilities here:

• It may be some form of electron issue (Is vivaldi also running on electron?)
• It may be connected to windows not running under native wayland but through xwayland instead (which wtype might have some issues with.

Do you know if these programs are running through wayland directly or through xwayland on your end?

[nicobonada]

Vivaldi is using chromium. I can reproduce the issue in chromium itself as well as electron apps like vesktop.

All apps running as native wayland clients according to hyprctl clients:

I tested by running wtype directly from the terminal and I get the same result so this is probably not a bug with bemoji:

This is with Hyprland 0.41.2 and wtype 0.4

[Fethbita]

If they do, it is probably an error on bemoji's end, if they still don't show up correctly it would probably be something in element.

I opened the file and pasted into Element, and the emoji appeared correctly.

Do you know if these programs are running through wayland directly or through xwayland on your end?

Element is running under wayland directly. I run it via the .desktop file and my Exec line is:

Exec=/usr/bin/element-desktop --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations --enable-webrtc-pipewire-capturer %u

swaymsg -t get_tree also shows xdg_shell.

[marty-oehme]

That exhausts most of my speculation and I think it may be true that it belongs more on the side of wtype.
It might be best to raise an issue over there or to see if there is already more discussion around such a bug on the project.

It may also be doable to create some scripted version using a different tool with the simple bemoji echo (bemoji --echo) but you would need some other tool that works well with the programs under all circumstances (perhaps ydotool or dotool could fit the bill?) to feed it into.
I am still a little puzzled why it works for me without issue to have bemoji type into the element-desktop application, however.

Thanks for the thorough investigation into this already @nicobonada!

[psynyde]

@Fethbita hi. did you find any solution for this issue? or maybe what's causing it? I'm suddenly facing the same issue after system update on every electron app. I'm pretty sure almost nothing was changed config wise as they're declared in nix config.

[Fethbita]

I work around it by using the clipboard support instead of inserting the emoji directly unfortunately :(

[marty-oehme]

Sorry to those for whom it seems a persistent issue. @psynyde it started happening after an update which also affected the electron apps (or the electron wrapper) in question?

Perhaps you can undertake a similar test as in #34 (comment) to see whether manually invoking the wtype type output is affected for the windows for all apps too. If it does also not work then this further solidifies my thinking that the issue lies in the interaction of wtype and the electron wrapper.

If so, unfortunately, there is not much I can do to fix this from my position right now, though we can perhaps put in an issue at wtype.
Going forward over the medium term we could think of finding alternative implementations to wtype and integrate them into bemoji for you to use instead, such as ydotool, dotool, or perhaps libei.

One big help would be some first tests if any of the tools work in a similar way to wtype and support typing emoji into arbitrary fields, so that we restrict our selection.