IBus misbehaving when using the Wayland backend

[alexnils]

Issue Description

As has been covered elsewhere (YaLTeR/niri#2476, and all of the links on that page), GTK4 applications now use Ibus when you want to compose letters using the compose key.

So in order to be able to use the compose key in applications like gnome-text-editor, Ptyxis and Ghostty, you have to install and start Ibus.

This works fine, but it introduces an annoying bug into Ghostty (Ptyxis, however, works fine). After enabling Ibus, Ghostty can't register non-printable keys (Enter, Delete, Arrow keys) after you switch focus to it in Niri or Hyprland. These keys only start working after typing a printable character.

So if you for example directly fire up a Ghostty terminal and paste something to it, no matter how many times you hit enter the text will not send (same with Arrow keys, Delete etc). These keys will only work if you print a letter first or press space.

A related issue is that after you have managed to compose a character like ā, š, etc, Ghostty freezes in the same manner. You can't delete the composed character until you insert a character or press space.

Ptyxis is also a GTK4 terminal, but it does not have this problem with Ibus in Niri / Hyprland, which makes me believe that this is a Ghostty issue with how it is handling Ibus in non-GNOME environments.

Expected Behavior

When switching to a Ghostty terminal window, one should be able to press Enter, Delete, Arrow keys without first having to type a letter.

Actual Behavior

Ghostty will not register Enter, Delete, Arrow keys etc. You have to first type something, then can you use these keys.

Reproduction Steps

How to reproduce:

1. Without having started Ibus, open gnome-text-editor, Ptyxis and Ghostty. Notice how the compose key is not working in these applications. Open another non-GTK application, like Alacritty, Kitty etc, and notice that the compose key works here.
2. Start Ibus: ibus start
3. Notice how the compose key now works in the GTK4 applications, but that only Ghostty is displaying the bug that I've described above. Also, try inputting a special character with the compose key, like the letter ā, notice how after the character has been created, the same "freezing" happens: you can't delete the character until you insert another character / press space.
4. Stop Ibus: ibus exit
5. Notice how the compose key does not work anymore, and that the bug in Ghostty cannot be reproduced.
6. In a terminal open up a new Ghostty instance with env GTK_IM_MODULE=ibus ghostty. Notice how the compose key works in the new terminal window now, and there is no bug!
7. Compose a letter and notice that there is no "freezing" afterwards, you can delete the character immediately.

This is not a hard bug to reproduce, I've been able to do it on two different machines running Niri and Hyprland. Note that this problem does not occur under GNOME.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.2.2-arch1

Version
  - version: 1.2.2-arch1
  - channel: tip
Build Config
  - Zig version   : 0.14.1
  - build mode    : builtin.OptimizeMode.ReleaseFast
  - app runtime   : apprt.Runtime.gtk
  - font engine   : font.main.Backend.fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 6.17.2-arch1-1
  - desktop env   : other
  - GTK version   :
    build         : 4.20.2
    runtime       : 4.20.2
  - libadwaita    : enabled
    build         : 1.8.1
    runtime       : 1.8.1
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

Arch

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

Niri / Hyprland

Minimal Ghostty Configuration

#I can reproduce it with a fresh configuration.

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[larsivi]

I have the same issue, Ghostty on Niri, IBus, EndeavourOS. It can be very disruptive in certain work-cases. E.g. I was switching to Ghostty with vim up, and in insert mode. The next thing to do, was Esc, but this didn't work. Similarly, while at the command line, a thing I wanted to do after switching there was Ctrl+R. Having to type something is rather contraproductive in both cases.

[OuiDelaportas]

I am having the exact same issue, Ghostty on Hyprland, IBus, CachyOS and vanilla Arch.

[larsivi]

I have debugged this a bit, first time opening a zig source file ... edited in some of the logging in src/apprt/gtk/class/surface.zig

Basically the variable im_composing is initially set to true for some reason. Whenever this is true, the handler returns early on stuff that corresponds with the failing things (return, Ctrl for Ctrl+R, pasting, etc). Having it set to false in imPreeditStart let me use this correctly whenever going to edit mode in the terminal (I have vi bindings). For the stuff happening after using dead-keys, for me just typing the ~ character to signify home, there is still an issue and the logs shows that unless it is a normal character, im_composing = true and nothing happens.

ibus is referenced here and there in the code, but the handling is definately not fully correct in this setting. I start my ibus with type=Wayland.

[fujiwarat]

My evaluation is mostly done in ibus/ibus#2819 and I also noticed im_composing and the timing issue recently.

[pluiedev]

I use Fcitx 5 myself and as such I've never encountered this issue — what I'd like to rule out is the possibility that this is a general IME bug. Could you all try to use Fcitx 5 instead and see if this is still reproducible? Otherwise, please also provide the exact IBus version down to the patch release, since IBus really likes to introduce slight behavior changes across even patch releases that we have to look out for.

[pluiedev]

Cross-referencing upstream issue at ibus/ibus#2819

[larsivi]

I can start with noting that I have
extra/ibus 1.5.32-1 (11.5 MiB 113.4 MiB) (Installed)

1.5.32 being noted as the version that has support for type=Wayland

[larsivi]

Yeah, fcitx5 seems to work from the intial test. I'm not wed to ibus, it was just the first thing that came up when I initially was missing the dead keys. I suppose I'll report back soonish when having done a more proper setup.

[pluiedev]

Alternatively, does GTK_IM_MODULE=ibus without Type=wayland work? Since there could be a bug with how IBus implements its Wayland text input protocol integration as well. Fcitx 5 in my experience works just fine via the text input protocol, which makes sense since it's had a lot more time fixing all the little bugs that might have arisen.

[OuiDelaportas]

I have debugged this a bit, first time opening a zig source file ... edited in some of the logging in src/apprt/gtk/class/surface.zig

Basically the variable im_composing is initially set to true for some reason. Whenever this is true, the handler returns early on stuff that corresponds with the failing things (return, Ctrl for Ctrl+R, pasting, etc). Having it set to false in imPreeditStart let me use this correctly whenever going to edit mode in the terminal (I have vi bindings). For the stuff happening after using dead-keys, for me just typing the ~ character to signify home, there is still an issue and the logs shows that unless it is a normal character, im_composing = true and nothing happens.

ibus is referenced here and there in the code, but the handling is definately not fully correct in this setting. I start my ibus with type=Wayland.

Using the findings mentioned here I just went to that file (src/apprt/gtk/class/surface.zig) and made the im_composing variable false everywhere, which works for me with ibus and mozc. It introduces some problems like the theme not being picked up and the resource directory not being set (this might be because I edited the "nightly" version and not a stable one but I am not well-versed enough to know if this it true) but I solved those problems quite easily and I prefer this over swapping to fcitx5. I will test it for a while to see if any problems arise and report back (maybe).

[pluiedev]

im_composing being set to true at start is definitely incorrect, though I struggle to see why it would be so at start. The only explanation is that somehow IBus is starting or changing the preedit before any character has been typed, which is fishy behavior on their part. I'll have to investigate this further, but if IBus is changing the preedit immediately then this runs against a fix we specifically added for a Fcitx 5 input method, which would be quite annoying to deal with.

[OuiDelaportas]

How would "investigate" this? I am just curious. I would really appreciate it if you just gave a layout of your process. Thanks.

[OuiDelaportas]

Everything was smooth for 10 days up to this point. Today OSC stopped working correctly, so any non-latin characters (e.g. 理由を表す) would be copied as their UTF-8 byte sequence (i.e. \E7\90\86\E7\94\B1\E3\82\92\E8\A1\A8\E3\81\99\0A). I recompiled for now and that fixed the issue.

[pluiedev]

That's #9668, which isn't really at all related to this issue