niri for some reason known only to itself does not send any pointer
leave/data device enter/data source events when it accepts a grab. The
only event it seems to send is surface enter on the drag icon surface,
and that too it sends that event much later.
Handle this bonkers behavior by retrying the sync multiple times to
detect if niri has accepted the drag or not.
Fixes#10271
The first OS window on Wayland is created at scale 1 because the
compositor only sends the fractional scale after the surface exists.
The initial size in cells is therefore computed with scale-1 cell
metrics and the window is mapped a few cells too small. The existing
post-map recompute calls glfwSetWindowSize(), but on Wayland that loses
to the compositor's authoritative configure, which re-asserts the size
it recorded at map time. So a window that receives focus (the normal
interactive case) stays too small; a background window that never gets
an activated configure happens to keep the resized value, which is why
it can look fixed.
Correct the size while the window is still unmapped instead. GLFW gains
a hook (glfwWaylandSetInitialWindowSizeCallback) that it invokes when
the fractional scale is applied during creation -- mutter, kwin and niri
send the scale before the first configure -- letting the embedder
recompute the cell-based logical size for the real scale before the
window is mapped. The compositor then records the correct size and its
activation configure agrees, so there is nothing to race.
The existing post-map recompute is kept as a fallback for compositors
that only send the scale after the first configure (sway, Hyprland).
Also add glfwCocoaSetWindowLevel to the glfw.py wrapper generator list:
it was present in the committed glfw-wrapper but missing from the
generator, so regenerating the wrapper (required to add the hook above)
would otherwise drop it and break the macOS build.
_glfwPlatformCreateWindow() ignored the return value of
attach_opengl_context_to_window(), so when EGL is unavailable (for
example libEGL cannot be loaded) it reported success with
window->context left zeroed. glfwCreateWindow() then proceeded to
_glfwRefreshContextAttribs() -> glfwMakeContextCurrent(), which calls
the NULL context.makeCurrent pointer: kitty crashes with SIGSEGV
instead of reporting "Failed to create GLFWwindow. This usually
happens because of old/broken OpenGL drivers." as intended. The X11
backend already propagates these failures.
Co-Authored-By: Claude <noreply@anthropic.com>
When a kitty window regains text-input focus (e.g. switching back to a
workspace in sway, unminimizing, or unlocking the screen), the
zwp_text_input_v3::enter event is fired. However, text_input_enter()
only called enable + set_content_type without restoring the cursor
rectangle. If the compositor does not re-send wl_keyboard.enter at the
same time, kitty never updates the IME position, causing the popup to
appear at the top-left corner.
Restore the last known cursor rectangle in text_input_enter() so the
IME popup immediately appears at the correct position.
Allow the first mouse click on an inactive Cocoa OS window to be delivered to kitty instead of only activating the window.
Make the matching kitty-internal behavior consistent by forwarding clicks that switch focus to another kitty window in the currently focused OS window. This lets the same first click both focus the target kitty window and perform the click action, including forwarding to mouse-tracking applications.
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>
inform_compositor_of_window_geometry() calls xdg_surface_set_window_geometry()
unconditionally, but layer-shell surfaces (e.g. those from `kitten panel`) have
no xdg_surface. With hide_window_decorations set to titlebar-only, the panel hits
this geometry call during creation and dereferences the NULL proxy, crashing in
wl_proxy_get_version() with SIGSEGV.
Guard on window->wl.xdg.surface: layer-shell surfaces manage geometry via the
layer surface, so the xdg call is skipped. Normal toplevels are unaffected.
Some window managers (e.g. kwin_x11) clear _NET_WM_STATE when a window
is unmapped/withdrawn. This caused layer shell windows to lose states like
_NET_WM_STATE_ABOVE, _NET_WM_STATE_SKIP_TASKBAR, etc. when hidden and
re-shown via toggle. The result was inconsistent behaviour between the
first show and subsequent shows.
Fix by calling update_wm_hints() before XMapWindow in
_glfwPlatformShowWindow() for layer shell windows, which re-applies all
WM state properties (_NET_WM_STATE, window type, strut, size hints)
before each map operation.
