zed is not accepting any keyboard event in window

[sudhirdhumal289]

Summary

Keyboard events are not recognized in zed on opening for first time.

Description

I recently updated the zed editor and started using it again after few days, but seems like its broken now as its not accepting any keyboard input. Its not accepting keyboard input anywhere in the window (editor, terminal etc)

Side Note: Mouse click works everywhere

System Details:

1. OS: Debian GNU/Linux trixie/sid (X11)
2. Hardware: Lenovo Legion 5i (CPU: i9-14900HX, GPU: GTX-4060, RAM: 32 GB)

Steps to reproduce:

1. I have one rust project with workspace and multiple crates in sub-folders.
2. On opening editor for first time on starting my Debian linux it started the indexing
3. While indexing was going on I tried to edit already open file
4. It does not accept any keyboard event
5. Restart the zed editor and it starts accepting the keyboard inputs

Expected Behavior: Doesnt matter if you open zed editor for 1st time or nth time it should accept the keyboard input in all cases as its an editor.

Actual Behavior: Its not really accepting keyboard inputs on first run.

Zed Version and System Specs

Zed: v0.182.11 (Zed) OS: Linux X11 debian unknown Memory: 31.1 GiB Architecture: x86_64 GPU: Intel(R) Graphics (RPL-S) || Intel open-source Mesa driver || Mesa 25.0.3-1

[smitbarmase]

By first run do you mean after installing fresh Zed, or everytime to you open your project?

[sudhirdhumal289]

First Run = Boot machine and login to x11 session and start zed editor

[isosphere]

I've been having the same issue recently.

~I'm using vim mode, perhaps that's relevant.~[^3]

[^3]: disabling vim mode and restarting does not change the symptoms

The problem begins on first run, after a few moments. Up until that point the keyboard functions. After that, there appears to be nothing I can do[^1] to make it work except restarting Zed, after which it works fine until the next time I restart my computer[^2].

I ran zed --foreground to see if the logs show anything, but the output isn't any different from when the keyboard works. I can consistently reproduce the behaviour.

Restarting sddm (my display manager) is not sufficient to reproduce the problem.

Zed 0.182.11 67ca67273f4066b703e3bed9d0a1a08b13010c43 The issue also occurs on 83d9f19234df4e0f327e95530658ad65d781235e, a3f070195111f8d80111cd73b8a26d7aa2228040, 276084c1437264143b5423ee7e7ca8d99c9e2f1f, and 163c638177c8df26c1ddbf537b19d3ebfb475714 (0.143.6), which is the last tagged version with an easy tarball of binaries to check with

might be caused by a library update

Operating System: Debian GNU/Linux 12 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.14.0-rc5 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics Memory: 27.1 GiB of RAM Graphics Processor: AMD Radeon 780M Manufacturer: LENOVO Product Name: 21K7000BUS System Version: ThinkPad T16 Gen 2

[^1]: switching vim mode on/off, switching tabs, closing terminal windows and opening them again [^2]: i've tried logging out and logging back in to my X11 session, no issue there. seems to be a fresh boot issue

[smitbarmase]

This definitely looks like only happening for Linux X11, I will try to reproduce it. Thank you detailed report.

[isosphere]

This same behaviour occurs in cargo run --example input for the gpui crate as of 266c41ed9a5d43d185acc46e0c8ac71d0cfbac3c; including working for a few moments until it ceases to register key presses.

Having restarted my computer and then running that example, a subsequent run of Zed does not exhibit the problem (the same behaviour as with Zed).

[smitbarmase]

I tried reproducing this issue on fresh Linux installation but had no luck. Typing in editor on opening Zed project on first run works just fine for me. This is what I'm using:

OS: Kubuntu 22.04 KDE Plasma Version: 5.24.7 Graphics Platform: X11 Graphics: Mesa Intel

So, it doesn't look like this happens on every X11 installation. @sudhirdhumal289 which OS are you using?

Is there any past version of Zed that works fine for you both? @isosphere If you can, try git bisecting to pinpoint from which commit this started to happen? Though this seems like a tedious task given this only happens on restart.

[isosphere]

OS: Kubuntu 22.04 KDE Plasma Version: 5.24.7 Graphics Platform: X11 Graphics: Mesa Intel

That version of KDE/Kubuntu came out 2.6 years ago. Might be better to try on a current release.

Is there any past version of Zed that works fine for you both? @isosphere If you can, try git bisecting to pinpoint from which commit this started to happen? Though this seems like a tedious task given this only happens on restart.

I've tried with every tagged release that has a binary tarball for installation as far back as 0.143.6 (dated about a year ago).

I suspect this is an interaction between Zed's gpui crate and a shared library dependency it uses.

Probably one of these? (as found in Cargo.toml for gpui):

• "as-raw-xcb-connection",
• "x11rb",
• "xkbcommon",

Here are my versions of shared libraries that look like that:

libxkbcommon: 1.7.0-2 libx11: 2:1.8.12-1 libxcb, libxcb-xkb, libxcb-xinput: 1.17.0-2+b1

Here's the ldd output on the input example:

linux-vdso.so.1 (0x00007f9c32950000)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f9c2ffd5000)
libX11-xcb.so.1 => /lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f9c32912000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f9c2fe8d000)
libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f9c2fdbd000)
libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f9c2fd72000)
libxkbcommon-x11.so.0 => /lib/x86_64-linux-gnu/libxkbcommon-x11.so.0 (0x00007f9c32905000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9c2fd52000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9c2fd25000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9c2fc35000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9c2fa3f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9c32952000)
libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f9c32900000)
libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f9c328f6000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f9c2fa2c000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f9c2f9f4000)
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f9c2f9e6000)
libxcb-xkb.so.1 => /lib/x86_64-linux-gnu/libxcb-xkb.so.1 (0x00007f9c2f9c7000)
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f9c2f9a2000)

[athre0z]

Same here on Debian testing / X11 / KDE. Also repros with Gnome. On first launch after boot Zed stops registering keystokes after a few seconds, then after restarting it is fine until I reboot -- even when restarting Zed.

[isosphere]

I fiddled with the gpui input example in a debugger and found that the keystroke handling here:

https://github.com/zed-industries/zed/blob/6f918ed99bfa107d496f7e6a7101a956494f3153/crates/gpui/examples/input.rs#L725-L728

... does not get called when this problem occurs, after being called for every keystroke leading up to the problem. I can click the reset button and that functions, so its not like all callbacks are dead.

I see that cx.observe_keystrokes is a gpui::Subscription. No Subscription::detach, remove or Drop occurs between the input working and the input not working.

The XimHandler::handle_forward_event key event here is also not being triggered when the issue occurs:

https://github.com/zed-industries/zed/blob/6f918ed99bfa107d496f7e6a7101a956494f3153/crates/gpui/src/platform/linux/x11/xim_handler.rs#L92-L94

I've set a breakpoint on XimHandler::handle_close and it did not occur.

I tried xim-rs's x11rb_client example on a fresh boot and mashed "asdf" a bunch. Eventually it started to return errors, which seems like a clue:

 INFO  x11rb_client::handler > Handle forward event ForwardEventFlag(SYNCHRONOUS), 40
 TRACE xim::x11rb            > ->: SyncReply { input_method_id: 1, input_context_id: 1 }
 TRACE x11rb_client          > Send: KeyPressEvent { .. }
 TRACE xim::x11rb            > ->: ForwardEvent { input_method_id: 1, input_context_id: 1, flag: ForwardEventFlag(0x0), serial_number: 222, xev: XEvent { response_type: 3, detail: 38, sequence: 222, time: 174163, root: 1016, event: 71303168, child: 0, root_x: 1411, root_y: 180, event_x: 502, event_y: -3, state: 16, same_screen: true } }
 TRACE xim::client           > <-: ForwardEvent { input_method_id: 1, input_context_id: 1, flag: ForwardEventFlag(SYNCHRONOUS), serial_number: 222, xev: XEvent { response_type: 3, detail: 38, sequence: 222, time: 174163, root: 1016, event: 71303168, child: 0, root_x: 1411, root_y: 180, event_x: 502, event_y: -3, state: 16, same_screen: true } }
 INFO  x11rb_client::handler > Handle forward event ForwardEventFlag(SYNCHRONOUS), 38
 TRACE xim::x11rb            > ->: SyncReply { input_method_id: 1, input_context_id: 1 }
 TRACE x11rb_client          > Send: KeyPressEvent { .. }
 TRACE xim::x11rb            > ->: ForwardEvent { input_method_id: 1, input_context_id: 1, flag: ForwardEventFlag(0x0), serial_number: 227, xev: XEvent { response_type: 3, detail: 39, sequence: 227, time: 174184, root: 1016, event: 71303168, child: 0, root_x: 1411, root_y: 180, event_x: 502, event_y: -3, state: 16, same_screen: true } }
 TRACE x11rb_client          > Send: KeyPressEvent { .. }
 TRACE xim::x11rb            > ->: ForwardEvent { input_method_id: 1, input_context_id: 1, flag: ForwardEventFlag(0x0), serial_number: 230, xev: XEvent { response_type: 3, detail: 40, sequence: 230, time: 174239, root: 1016, event: 71303168, child: 0, root_x: 1411, root_y: 180, event_x: 502, event_y: -3, state: 16, same_screen: true } }
 TRACE x11rb_client          > Send: KeyPressEvent { .. }
 TRACE xim::x11rb            > ->: ForwardEvent { input_method_id: 1, input_context_id: 1, flag: ForwardEventFlag(0x0), serial_number: 233, xev: XEvent { response_type: 2, detail: 38, sequence: 233, time: 176234, root: 1016, event: 71303168, child: 0, root_x: 1411, root_y: 180, event_x: 502, event_y: -3, state: 16, same_screen: true } }
 ERROR x11rb_client          > X11Error: X11Error { error_kind: Window, error_code: 3, sequence: 235, bad_value: 4194311, minor_opcode: 0, major_opcode: 18, extension_name: None, request_name: Some("ChangeProperty") }
 ERROR x11rb_client          > X11Error: X11Error { error_kind: Window, error_code: 3, sequence: 236, bad_value: 4194311, minor_opcode: 0, major_opcode: 25, extension_name: None, request_name: Some("SendEvent") }
 TRACE x11rb_client          > Send: KeyPressEvent { .. }
 TRACE xim::x11rb            > ->: ForwardEvent { input_method_id: 1, input_context_id: 1, flag: ForwardEventFlag(0x0), serial_number: 236, xev: XEvent { response_type: 3, detail: 38, sequence: 236, time: 176334, root: 1016, event: 71303168, child: 0, root_x: 1411, root_y: 180, event_x: 502, event_y: -3, state: 16, same_screen: true } }
 ERROR x11rb_client          > X11Error: X11Error { error_kind: Window, error_code: 3, sequence: 238, bad_value: 4194311, minor_opcode: 0, major_opcode: 18, extension_name: None, request_name: Some("ChangeProperty") }
 ERROR x11rb_client          > X11Error: X11Error { error_kind: Window, error_code: 3, sequence: 239, bad_value: 4194311, minor_opcode: 0, major_opcode: 25, extension_name: None, request_name: Some("SendEvent") }
 TRACE x11rb_client          > Send: KeyPressEvent { .. }
 TRACE xim::x11rb            > ->: ForwardEvent { input_method_id: 1, input_context_id: 1, flag: ForwardEventFlag(0x0), serial_number: 239, xev: XEvent { response_type: 2, detail: 133, sequence: 239, time: 182473, root: 1016, event: 71303168, child: 0, root_x: 2667, root_y: 846, event_x: 1758, event_y: 663, state: 16, same_screen: true } }
 ERROR x11rb_client          > X11Error: X11Error { error_kind: Window, error_code: 3, sequence: 241, bad_value: 4194311, minor_opcode: 0, major_opcode: 18, extension_name: None, request_name: Some("ChangeProperty") }
 ERROR x11rb_client          > X11Error: X11Error { error_kind: Window, error_code: 3, sequence: 242, bad_value: 4194311, minor_opcode: 0, major_opcode: 25, extension_name: None, request_name: Some("SendEvent") }

If I restart the example and mash some more, nothing shows up by default because the handler is not connected; however the example does receive the keystrokes and I can log them. This appears to be the situation when Zed works after a close/open.

These dmesg lines occur when the x11rb_client handler fails:

[  284.036140] ibus-x11[2813]: segfault at 2ce ip 00007f0c79604356 sp 00007ffe766e79b0 error 4 in libgdk-3.so.0.2417.32[9c356,7f0c79596000+87000] likely on CPU 5 (core 2, socket 0)
[  284.036175] Code: 4c 89 0c 24 e8 db f0 ff ff 44 8b 54 24 18 41 81 e2 ff 9f ff ff 45 09 d4 44 3a 68 0c 0f 82 c2 01 00 00 48 8b 78 20 41 0f b6 cd <48> 8b 57 20 48 8d 0c ca 44 0f b6 41 04 44 89 c6 83 e6 0f 44 38 68

On Debian, this library is provided by libgtk-3-0t64. Looks like there's a similar bug report. I've reinstalled it and rebooted, but now input doesn't work in Zed at all until a second start, and there is no segfault in my logs. I can't reproduce the segfault anymore, and Zed input doesn't work at all on a fresh boot until I close it and open it again.

I've sent in the backtrace from my latest coredump to the Debian maintainer, though my inability to replicate the segfault despite still having Zed input issues implies it may be unrelated.

[SamD]

Just tried zed for the first time , looks great unfortunately it takes no keyboard input anywhere, extensions, text editor, llm chat nothing ... very odd

[Nindaleth]

@SamD This issue tracks Zed not accepting keyboard input after starting it for the first time only (every 1st time after OS boot), subsequent attempts should work normally. If your experience matches that description, you may consider adding your thumbs-up vote to the first message.

If you don't get any keyboard input even on subsequent runs, that would be unexpected.

[SamD]

After a restart it was fine , but the first time after the install that is what happened

Sent from Proton Mail Android

-------- Original Message -------- On 7/16/25 12:49 AM, Nindaleth wrote:

Nindaleth left a comment (zed-industries/zed#29083)

@.***(https://github.com/SamD) This issue tracks Zed not accepting keyboard input after starting it for the first time only (every 1st time after OS boot), subsequent attempts should work normally. If your experience matches that description, you may consider adding your thumbs-up vote to the first message.

If you don't get any keyboard input even on subsequent runs, that would be unexpected.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[smitbarmase]

@isosphere can you check if it is still happening for you after https://github.com/zed-industries/zed/pull/34514?

[isosphere]

@isosphere can you check if it is still happening for you after #34514?

I built a release version of d4110fd2ab and there is no change, unfortunately. Text input stops working after some keyboard spam on the first run, then on the second run there's no problem.

[Nindaleth]

I can confirm that the issue is not fixed on stable 0.196.5.

Not only that, I looked at #34514 and I don't see any change before or after its merging despite my using both Linux, X11 and Czech keyboard layout, which is suspicious.

Except for this open issue, I don't have (nor had) any other keyboard-input related issues on my environment.

[smitbarmase]

@isosphere I tried reproducing it on latest KDE, unfortunetly still no luck. Stable, Preview and Dev build works just right for me upon first install as well as first open after restart.

Operating System: Kubuntu 25.04 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 Kernel Version: 6.14.0-27-generic (64-bit) Graphics Platform: X11 Processors: 28 × Intel® Core™ i7-14700K Memory: 31.0 GiB of RAM Graphics Processor: Intel® Graphics Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7D90 System Version: 2.0

[cpuccino]

I don't think this is just on x11, been running into this issue for a while on Wayland.

Ubuntu 25.04 Gnome 48 Wayland Kernel 6.14.0-27-generic

---

edit:

Turns out I configured it to run on x11/xwayland because I wanted the native title bars. Restarted multiple times and ran zed on wayland and it seems fine.

Does seem like this is only an issue on x11 or xwayland.

[theodoregoetz]

I see this issue with Wayland on Fedora 42. It seems very consistent. The first start-up of zed after a reboot ignores keyboard input after a short while (minutes to seconds). This is true for opening a local project and when opening a remote project over ssh (With the zed ssh://... command). Note that I always startup zed from the terminal. I do have two GPUs on this laptop (integrated Intel and a discrete Nvidia). I'm not sure which one zed is using, but my desktop (Gnome) is running on the Intel graphics with the Mesa driver.

 OS: Fedora 
 Kernel: x86_64 Linux 6.15.8-200.fc42.x86_64
 Uptime: 7m
 Packages: 3781
 Shell: zsh 5.9
 Resolution: No X Server
 DE: GNOME 48.3
 WM: Mutter
 WM Theme: Adwaita
 GTK Theme: Adwaita [GTK2/3]
 Icon Theme: Adwaita
 Font: Adwaita Sans 11
 Disk: 837G / 3.9T (22%)
 CPU: 11th Gen Intel Core i9-11900H @ 16x 4.8GHz [50.0°C]
 GPU: Mesa Intel(R) UHD Graphics (TGL GT1)
 RAM: 4728MiB / 31808MiB

[isosphere]

@theodoregoetz , @cpuccino: do you see lines like the following in dmesg when you have input problems?

[  284.036140] ibus-x11[2813]: segfault at 2ce ip 00007f0c79604356 sp 00007ffe766e79b0 error 4 in libgdk-3.so.0.2417.32[9c356,7f0c79596000+87000] likely on CPU 5 (core 2, socket 0)
[  284.036175] Code: 4c 89 0c 24 e8 db f0 ff ff 44 8b 54 24 18 41 81 e2 ff 9f ff ff 45 09 d4 44 3a 68 0c 0f 82 c2 01 00 00 48 8b 78 20 41 0f b6 cd <48> 8b 57 20 48 8d 0c ca 44 0f b6 41 04 44 89 c6 83 e6 0f 44 38 68

[cpuccino]

@isosphere Sorry no, there doesn't seem to be any errors related to libgdk

[smitbarmase]

I can reproduce this on Ubuntu 25.04. Upon startup, when we’re connected to XIM, it only responds to the first few forward_events and then stops completely. I’m not sure why, it might be an upstream issue, or maybe we’re not doing state tracking correctly on Zed’s side.

Rolling back even a year in the commit history doesn’t fix it, so maybe something changed in newer Ubuntu releases and we need to adapt. After restarting Zed, input works correctly because XIM doesn’t connect at all, we just process input events directly. That suggests XIM is completely broken on Ubuntu.

I’d appreciate a look from someone with XIM knowledge. I’ll keep digging in the meantime.

[Nindaleth]

FWIW here's a backtrace of a segfault I get on Fedora 42 (GNOME) only on the first Zed start; I didn't see it mentioned yet and I missed it initially as I didn't get anything in dmesg, only in journalctl.

Backtrace:

#0  0x00007f0f8a49e09c __pthread_kill_implementation (libc.so.6 + 0x7309c)
#1  0x00007f0f8a444a7e raise (libc.so.6 + 0x19a7e)
#2  0x00007f0f8a42c6d0 abort (libc.so.6 + 0x16d0)
#3  0x00007f0f8a42d6f3 __libc_message_impl.cold (libc.so.6 + 0x26f3)
#4  0x00007f0f8a4a81f5 malloc_printerr (libc.so.6 + 0x7d1f5)
#5  0x00007f0f8a4a8d2b unlink_chunk.isra.0 (libc.so.6 + 0x7dd2b)
#6  0x00007f0f8a4a8eb3 malloc_consolidate (libc.so.6 + 0x7deb3)
#7  0x00007f0f8a4ab930 _int_malloc (libc.so.6 + 0x80930)
#8  0x00007f0f8a4ae196 __libc_calloc (libc.so.6 + 0x83196)
#9  0x0000558a2969446a _Xi18nChangeIC (/usr/libexec/ibus-x11 + 0x1146a)
#10 0x0000558a2968ff59 _Xi18nMessageHandler (/usr/libexec/ibus-x11 + 0xcf59)
#11 0x0000558a29692e2d WaitXIMProtocol (/usr/libexec/ibus-x11 + 0xfe2d)
#12 0x00007f0f8ab5b19f _gdk_x11_display_queue_events (libgdk-3.so.0 + 0x6e19f)
#13 0x00007f0f8aafc18b gdk_display_get_event (libgdk-3.so.0 + 0xf18b)
#14 0x00007f0f8ab5bade gdk_event_source_dispatch.lto_priv.1 (libgdk-3.so.0 + 0x6eade)
#15 0x00007f0f8a7a9880 g_main_context_dispatch_unlocked.lto_priv.0 (libglib-2.0.so.0 + 0x40880)
#16 0x00007f0f8a7b27c8 g_main_context_iterate_unlocked.isra.0 (libglib-2.0.so.0 + 0x497c8)
#17 0x00007f0f8a7b2a6f g_main_loop_run (libglib-2.0.so.0 + 0x49a6f)
#18 0x00007f0f8ac1cc10 ibus_main (libibus-1.0.so.5 + 0x36c10)
#19 0x0000558a29684750 main (/usr/libexec/ibus-x11 + 0x1750)
#20 0x00007f0f8a42e575 __libc_start_call_main (libc.so.6 + 0x3575)
#21 0x00007f0f8a42e628 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3628)
#22 0x0000558a29684935 _start (/usr/libexec/ibus-x11 + 0x1935)

[smitbarmase]

I can now reproduce it without rebooting or logging out:

1. Open Zed on Ubuntu 25.04 and type a few characters, ibus crashes.

2. Close Zed, then run:

   ps aux | grep ibus
   

   Output looks like:

   smit       26668  0.1  0.0 601904 10536 ?        Ssl  01:46   0:00 /usr/bin/ibus-daemon --panel disable --xim
   smit       26679  0.0  0.0 172344  6740 ?        Sl   01:46   0:00 /usr/libexec/ibus-memconf
   smit       26680  3.8  0.1 286028 30740 ?        Sl   01:46   0:01 /usr/libexec/ibus-extension-gtk3
   smit       26690  0.0  0.0 311728  6900 ?        Sl   01:46   0:00 /usr/libexec/ibus-portal
   smit       26702  0.0  0.0 172472  7016 ?        Sl   01:46   0:00 /usr/libexec/ibus-engine-simple
   smit       26833  0.0  0.0   8888  1948 pts/0    S+   01:46   0:00 grep --color=auto ibus
   

   Note there’s no ibus-x11 process. If I relaunch Zed now, it works because input goes direct (not via XIM).

3. With Zed closed, restart ibus:

   ibus restart
   

4. Launch Zed again, type a few characters. Crash reproduces!

[smitbarmase]

@Nindaleth can you confirm ibus version by running rpm -q --qf "%{VERSION}-%{RELEASE}" ibus?

[Nindaleth]

@smitbarmase Here it is:

$ rpm -q --qf "%{VERSION}-%{RELEASE}" ibus
1.5.32-1.fc42

[Nindaleth]

Also here's a list of possibly available package versions and their Fedora versions: https://koji.fedoraproject.org/koji/packageinfo?packageID=6599

Maybe it would be safer to skip the whole 1.5.32* thing?

[smitbarmase]

@Nindaleth I'm also curious if you are on Fedora. This should not happen for you as you'll be using Zed's Wayland variant. I wonder if you are forcing Zed to run through X11 via XWayland. Try running xlsclients in terminal while Zed is open.

[Nindaleth]

@smitbarmase yes, I'm on Fedora 42. Nowadays Wayland is the default on new Fedora installations, but I'm still running X11 and that's why I can reproduce.

[Nindaleth]

xlsclients lists my running processes and some of the system stuff, but no Zed on the list (on both the ibus-crashing run and the folowing one).

[smitbarmase]

This is fixed upstream. Read more: https://github.com/ibus/ibus/issues/2789.