GNOME Wayland busy cursor persists ~15s after launch

[nitipit]

Summary

On Fedora GNOME Wayland, launching Zed leaves the mouse cursor in GNOME's busy/loading state for about 15 seconds. The Zed window is visible and usable immediately; only the global cursor feedback remains busy until it times out.

The busy cursor appears everywhere, not just over the Zed window.

Environment

• Zed: 1.6.3 stable.306, commit 601ecb3ee5c16940191818ee7f244837abf6983c
• Install method: official per-user install under ~/.local/zed.app
  • CLI: ~/.local/bin/zed -> ~/.local/zed.app/bin/zed
  • App binary: ~/.local/zed.app/libexec/zed-editor
• OS: Fedora release 44 (Forty Four)
• GNOME Shell: 50.2
• Session: Wayland
  • XDG_SESSION_TYPE=wayland
  • XDG_CURRENT_DESKTOP=GNOME
  • WAYLAND_DISPLAY=wayland-0

Reproduction

1. Launch Zed from GNOME app launcher, or from terminal with zed.
2. Zed window appears and is usable immediately.
3. Mouse cursor stays in the GNOME loading/busy state globally for about 15 seconds.
4. Cursor then returns to normal.

This happens even when launching from terminal, not only from the app launcher.

Expected behavior

The cursor should return to the normal pointer once the Zed window is visible/ready.

Actual behavior

The cursor remains in GNOME's busy/loading state globally for about 15 seconds, despite Zed being visible and usable.

Things tested

Desktop file StartupNotify

The installed desktop entry originally had:

StartupNotify=true
Exec=/home/user/.local/zed.app/bin/zed %U

I tested copied/local desktop entries with:

StartupNotify=false

and also patched the original local desktop entry to StartupNotify=false. The problem still occurs.

Debug launcher wrapper

A wrapper launcher with StartupNotify=false showed no startup notification env vars being passed:

DESKTOP_STARTUP_ID=
XDG_ACTIVATION_TOKEN=
GIO_LAUNCHED_DESKTOP_FILE=/home/user/.local/share/applications/dev.zed.Zed-debug-no-startupnotify.desktop
XDG_CURRENT_DESKTOP=GNOME
XDG_SESSION_TYPE=wayland

The cursor still remained busy for ~15 seconds.

CLI variants

• zed: starts quickly; cursor still becomes busy globally for ~15 seconds.
• zed --foreground: starts and renders first frame immediately.
• zed --disable-gpu: not accepted by this CLI version:

error: unexpected argument '--disable-gpu' found

Relevant Zed logs

Startup appears fast; first frame is rendered immediately:

INFO  [zed] ========== starting zed version 1.6.3+stable.306.601ecb3ee5c16940191818ee7f244837abf6983c, sha 601ecb3 ==========
INFO  [gpui_wgpu::wgpu_context] Selected GPU adapter: "Intel(R) Graphics (LNL)" (Vulkan)
INFO  [workspace] Rendered first frame
INFO  [zed::zed] Using GPU: GpuSpecs { is_software_emulated: false, device_name: "Intel(R) Graphics (LNL)", driver_name: "Intel open-source Mesa driver", driver_info: "Mesa 26.0.8" }
ERROR [gpui_linux::linux::wayland::client] activation token received with no pending activation

Other related logs seen during startup:

INFO  [gpui_linux::linux::platform] activate is not implemented on Linux, ignoring the call

WAYLAND_DEBUG observations

With WAYLAND_DEBUG=1 zed --foreground, Zed sets the expected app id:

xdg_toplevel.set_app_id("dev.zed.Zed")

Then it requests activation tokens with serial 0 and activates the surface:

xdg_activation_token_v1.set_app_id("dev.zed.Zed")
xdg_activation_token_v1.set_serial(0, wl_seat)
xdg_activation_token_v1.set_surface(wl_surface#29)
xdg_activation_token_v1.commit()
xdg_activation_v1.activate("..._TIME0", wl_surface#29)

Given the log message activation token received with no pending activation, this may be related to Wayland activation/startup notification handling under GNOME.

Additional note

Because the busy cursor appears everywhere, this seems to be GNOME Shell launch feedback/activation timeout rather than Zed setting a cursor shape only over its own window.

[yeskunall]

Reproduction steps

1. Install Zed on Fedora GNOME.
2. Verify that the Zed desktop entry contains:
   StartupNotify=true
3. Launch Zed from the GNOME application launcher or app grid.
4. Wait for the Zed window to appear.

Optional:
5. Close Zed and repeat several times.

Current vs. Expected behavior

Current behavior:
Zed launches and becomes usable, but the mouse cursor remains in the GNOME "loading/spinning" state after the window is already visible. The loading cursor only disappears after a timeout or after interacting with the desktop/window manager.

Expected behavior:
Once the Zed window is created and ready for user interaction, the startup notification should be completed and the cursor should immediately return to its normal state.

Zed version and system specs

Zed: v1.4.4+stable.297.1d0b482638588e5507184d91631e30596339ee1b (Zed)
OS: Linux Wayland fedora 44
Memory: 15.3 GiB
Architecture: x86_64
GPU: Intel(R) Graphics (RPL-U) || Intel open-source Mesa driver || Mesa 26.0.8

Attach Zed log file

Zed.log

Relevant Zed settings

settings.json

Relevant Keymap

keymap.json

(for AI issues) Model provider details

No response

If you are using WSL on Windows, what flavor of Linux are you using?

None

---

Originally posted by @CismicCat in #58923

[yeskunall]

Thanks for the unusually thorough report -- the WAYLAND_DEBUG trace and the StartupNotify on/off testing are exactly what’s needed here. For whoever picks this up: related to #33897, which ties the GNOME launch-feedback timeout to mutter (https://gitlab.gnome.org/GNOME/mutter/-/issues/2689). Note that in #33897, StartupNotify=false mitigation does not fix this one (tested above) -- which points at Zed’s own self-activation call, requesting an activation token with serial 0, rather than the desktop-file startup-notification path.

I’ll need a GNOME Wayland env to repro. @miguelraz what’s your Linux setup looking like these days?

[niv]

I'm also on F44 and I see the same.

The same cursor pops up when you summon a new window inside Zed (Shift-Ctrl-N), so it can't be related to the app shortcut StartupNotify (I previously tried setting false in the shortcut and it does nothing).

To help diag, I checked out TOT from git, compiled it, and asked a LLM to try and find the issue.

FWIW, the attached patch fixes the misbehaviour on my machine.

59397.patch

Notes summarised from the model thread:

Summary

On Fedora 44 (GNOME 48/Mutter), opening a window in Zed causes a spinning busy cursor that persists indefinitely. The root cause is that the Wayland backend never properly resolves the compositor's startup notification.

Problem 1: Wrong serial kind in xdg-activation tokens

activate() used get_serial(SerialKind::MousePress) when requesting an xdg-activation token. When a new window is opened via a keyboard shortcut (Ctrl+Shift+N) or at initial launch with no prior mouse click, this returns 0. Wayland compositors silently reject activation tokens with serial 0, leaving the startup notification (busy cursor) unresolved indefinitely.

Fix: Use get_serial_latest() instead, which returns the most recent serial across all kinds (key press, mouse press, etc.). The SerialTracker already had this method with a doc comment diagnosing exactly this pattern: "using 0 causes compositors to silently reject the request."

Problem 2: Double-activation racing

map_window() (called during Window::new) now immediately sends an activation token request. But the existing activate_window() call in Workspace::new_local would send a second token, overwriting the first's pending_activation slot. The first token's async done response would then consume the slot meant for the second, and the second would log activation token received with no pending activation.

Fix: Check has_pending_activation() in activate() before sending a new request, skipping the redundant call.

Files changed

• crates/gpui_linux/src/linux/wayland/client.rs — Added get_serial_latest() and has_pending_activation() helper methods
• crates/gpui_linux/src/linux/wayland/window.rs — Fixed activate() to use latest serial and guard against double-activation; implemented map_window() to send activation at the earliest possible moment