The pointer_button_count check added in dc36e2165 uses the client side
view of the implicit grab, which is stale when the button release is
still in flight: glfwStartDrag passes the check, but by the time the
compositor processes wl_data_device.start_drag the implicit grab is
gone and the request is silently dropped. The data source then never
receives any event, so the tab drag state leaks forever, hijacking
mouse handling again, and the already created xdg_toplevel_drag
toplevel gets mapped as a stray undecorated window showing the drag
thumbnail that nothing ever destroys.
Detect this deterministically using protocol ordering: issue a
wl_display.sync right after start_drag. An accepted start_drag
synchronously produces events (wl_pointer.leave from the DND grab
taking over, wl_data_device.enter, wl_data_source events) that are
ordered before the sync callback. If the callback fires with none of
them seen, the request was dropped: cancel the drag, which notifies
the application (clearing the tab drag state) and destroys the drag
toplevel and data source.
Also defer mapping the drag toplevel until the session is confirmed,
so the stray window can never appear, not even for one frame.
Verified against headless GNOME Shell 50.2 (mutter) with injected
pointer timing scans: the unpatched build deadlocks with an orphaned
drag toplevel within ~13 fast flicks, the patched build catches every
race hit and cancels cleanly, with no deadlock, no stray window, and
normal slow drag/reorder/detach behaviour preserved.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
A quick click-and-flick on a tab could leave all of kitty with mouse
input permanently redirected to the tab bar, making every window
unclickable and text selection impossible.
Starting a tab drag is asynchronous: the drag thumbnail is rendered on
the next frame before glfwStartDrag is called. If the button is
released in that window, wl_data_device_start_drag is sent with a stale
serial that no longer matches an active pointer implicit grab, so the
compositor silently ignores it. The wl_data_source then never receives
any event, on_drag_source_finished never runs, and the
tab_being_dragged state is stuck forever, hijacking all mouse events.
Fix in layers:
- glfw/Wayland: track the implicit grab (serial of the first button
press and pressed-button count), use that serial for start_drag and
refuse with EAGAIN when there is no active implicit grab instead of
letting the compositor silently drop the request
- mouse.c: a left button release arriving while a tab drag is marked
started but no system DND is active means the drag never launched
(an active DND consumes the release on all platforms), so clear the
drag state instead of waiting for DND events that will never come
- tabs.py: handle OSError from start_drag_with_data for tab drags the
same way window drags already do; clear the potential-drag state when
the release lands on the new-tab button or empty tab bar area
- tabs.py/boss.py: clear drag state on drag finish/drop even when the
dragged tab has already been closed
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Hide the CSD titlebar subsurface while keeping shadow borders for
resizing. On SSD compositors (GNOME), forces CSD mode to draw
kitty's own shadows without a titlebar.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
As is typical with Wayland, the protocol is poorly designed and
implemented even worse. Hyprland 0.53 has completely broken color
management.
https://github.com/hyprwm/Hyprland/discussions/12788
In addition it and mangowc crash when using color management with nouveau drivers.
https://github.com/kovidgoyal/kitty/issues/9030
KDE kwin does not support the sRGB transfer function. And the geniuses
at Wayland are any way planning to deprecate sRGB as a transfer function.
Only GNOME mutter seems to get it right.
Then there are people that are likely going to shoehorn this into EGL
instead of leaving it under application control via the protocol anyway.
https://github.com/KhronosGroup/EGL-Registry/issues/197
Sigh. Wayland.
For some reason destroying the shadow surfaces causes mutter to render one of them at its old relative position. So workaround by not destroying the surfaces, modern mutter anyway seems to hide them when the window is docked.
Fixes#7701
Apparently NVIDIA drivers dont handle this well. Sigh.
Go back to calling wl_egl_window_resize() before resizing the
framebuffer instead of before swapping in the resized framebuffer.
Logically, these should be equivalent, but...
Wayland is such an ongoing disaster.
Fixes#7493 (I hope).
Call wl_egl_window_resize just buffer swapping buffers at which point
the context is already correct.
Also might workaround bugs in the NVIDIA driver: https://github.com/NVIDIA/egl-wayland/issues/52
