2038698 - [X11] on linux mint, dragging a tab over a kitty window makes the whole screen freeze

Status: UNCONFIRMED

(Core :: Widget: Gtk, defect)

Description

[David Jean-Bossard]

Steps to reproduce:

on linux mint with a kitty session open, when I drag a firefox tab out of the browser and over the kitty window

Actual results:

whole screen freezes; mouse OK, keyboard OK (num lock led) but not accepting window-related shortcuts (e.g. ctrl+w);
only way is to TTY (ctrl+alt+f2) then pkill -9 firefox then (ctrl+alt+f7) back

diagnosis session with Claude tracked down to :

"
Kitty registers EnterWindow — Ghostty does not. When the browser holds a GrabModeSync grab and you move the mouse into Kitty's window, X11 queues an EnterNotify event for Kitty. Since the grab is sync, the entire X11 event queue freezes waiting for the browser to call XAllowEvents to process it — which never happens because the browser's drag state is broken.
Ghostty doesn't register EnterWindow so no event gets queued, the grab stays in whatever broken state it's in, but nothing deadlocks.
Kitty needs EnterWindow for its functionality (cursor changes, focus_follows_mouse, enter/leave detection) so you can't just remove it from Kitty's side without patching Kitty itself.
The fix has to come from the browser side — it needs to use GrabModeAsync instead of GrabModeSync for tab drags, or release the grab properly on failure. That's a Gecko bug.
"

Expected results:

no freeze

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Can you create screencast of the issue?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Create_screenshot/screencast_for_a_bug_report
Thanks.

Comment 3

[David Jean-Bossard]

Attachment: firefox-tab-drag-kitty-freeze.mp4

showcase the 2 situations:

• dragging over ghostty is OK (I can focus other windows)
• dragging over kitty freezes as soon as I enter the kitty window

Comment 4

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Thanks. Please run the broken drag with MOZ_LOG="WidgetDrag:5" env variable, reproduce the issue and attach the log here. For instance as:

MOZ_LOG="WidgetDrag:5" firefox > log.txt 2>&1

and attach log.txt here.
Thanks.

Comment 5

[David Jean-Bossard]

Attachment: log with MOZ_LOG="WidgetDrag:5"

Comment 6

[Martin Stránský [:stransky] (ni? me) (PTO till June 6)]

Thanks, but please attach the actual file content, not a file path.

Comment 7

[David Jean-Bossard]

Oups, sorry ! Then I guess I should file a bug to Waterfox, this was the result of drag-dropping the file in the dedicated dop zone :sweat_smile:
(please note the current issue of tab-dragging actually occurs on Firefox)

Comment 8

[David Jean-Bossard]

Attachment: log.txt

Comment 9

[Thinker Li [:sinker]]

I looked at the log and the video. A few things suggest the explanation in comment #0 may not be right:

1. GDK does not use GrabModeSync. The grab code in gdk all uses GrabModeAsync. So an EnterNotify cannot freeze the X event queue the way comment #0 describes.

2. The WidgetDrag:5 log shows Firefox finishes the drag cleanly: SourceEndDragSession(GTK_DRAG_RESULT_SUCCESS) -> EndDragSessionImpl -> ~nsDragSession. The "channel error" lines after that are just child processes dying after pkill -9.

3. The video shows pointer events still being delivered during the freeze. So the X event queue is not blocked.

4. However, the cursor stays in the drag shape after the drop — it doesn't change back to the normal pointer. So something is still off, even though points 1–3 look fine.

The sync-grab idea doesn't fit what we see.

By the way, the log seems to be inconsistent with the video. The video show dropping on kitty will be canceled (the snapshot fly back to the tab bar). But, the log shows it success.