A drag icon stays on screen as a "pointer drag icon" window after the drag ends, while the client keeps the surface #1527

Windows build number:

10.0.26300.9711

Your Distribution version:

24.04

Your WSL versions:

WSL version: 2.7.13.0
Kernel version: 6.18.33.2-2
WSLg version: 1.0.73.2
MSRDC version: 1.2.7214
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26300.9711

Steps to reproduce:

Ubuntu 24.04, GTK 3.24.41 (libgtk-3-0t64 3.24.41-4ubuntu1.3), PyGObject 3.48.2 (python3-gi 3.48.2-1), monitors at 225% (216 dpi) and 100% (96 dpi).

1. Save the script in Each tab drag under WSLg leaves a "pointer drag icon" window on the Windows desktop endavis/gnome-connection-manager#401 (comment) as drag-repro.py, and run GDK_BACKEND=wayland CONTROL_DELAY_MS=20 python3 drag-repro.py.
2. Press on the tab first two, drag it down into the page below the tabs, then on outside every Linux window, onto the Windows desktop, and let go.

WSL logs:

/mnt/wslg/versions.txt gives weston 04d436c7d9a0cd55fa64b6612c7fa678d6fcd077, FreeRDP c4030980b29322a9cb2190711a5fadeeeb8b6a33 and Azure Linux 3.0.20260510.

weston.log logged one line as the drag began, and nothing when it ended:

[20:25:37.234] Client: ClientGetAppidReq: WindowId:0x3c4 does not have appId, or not top level window.

WSL dumps:

Not collected.

Expected behavior:

The drag icon goes when the drag ends. Of wl_data_device.start_drag's icon, the Wayland protocol says: "When the use as an icon ends, the current and pending input regions become undefined, and the wl_surface is unmapped."

Actual behavior:

A grey rectangle stays where the drag ended until that part of the screen is redrawn. Windows keeps a window for it, titled pointer drag icon (Ubuntu-24.04), of class RAIL_WINDOW, with a taskbar entry whose close button does not close it. The window goes only when the client exits.

EnumWindows, limited to WSLg's msrdc.exe, before and after the drag:

before:  'pointer drag icon' windows: 0
after:   'pointer drag icon' windows: 1
    0x3A0FA0  phys=149x48@965,502  default=66x21@429,223  dpi=216  RAIL_WINDOW  pointer drag icon (Ubuntu-24.04)
after the client exits:  'pointer drag icon' windows: 0

The client's WAYLAND_DEBUG=client log shows that Weston ended the drag, and that the client kept the icon surface, wl_surface@51: nothing destroys it.

$ grep -an 'start_drag(wl_data_source@58\|wl_data_source@58.cancelled\|wl_surface@51.destroy' control.log
13487:[ 781249.624]  -> wl_data_device@21.start_drag(wl_data_source@58, wl_surface@12, wl_surface@51, 21868)
14817:[ 782522.455] wl_data_source@58.cancelled()
26312:[ 941149.492] wl_data_source@58.cancelled()

The second cancelled() came 110 ms after a later start_drag, for wl_data_source@70, a drag from the script's plain drag source.

Why the client keeps the surface

That part is a GTK 3 bug, and it is not WSLg's. Under Wayland, GtkNotebook begins a second drag when motion reaches it before the compositor has taken the pointer; the script's 20 ms in drag-begin lets that motion arrive. GDK then ignores cancelled for the first drag's source, so the drag never ends inside GTK and its icon surface lives on. The measurements are in endavis/gnome-connection-manager#401 and endavis/gnome-connection-manager#406.

Whatever the client keeps, the compositor has ended the drag. The surface is no longer an icon, so it should not be shown.

From the source at 04d436c7

• libweston/backend-rdp/rdprail.c creates a RAIL window for every surface, on the compositor's create_surface_signal, and removes it only on the surface's destroy_signal.
• rdp_rail_update_window logs "surface has no view", and leaves the window as it is.
• libweston/data-device.c, data_device_end_drag_grab, unmaps and destroys the icon's view and clears the surface's label when the drag ends.

So the RAIL window outlives the icon's view. Hiding a RAIL window whose surface has no view left, or whose drag-icon role has ended, would match the protocol.