Drag'n'drop blocks GUI

[dirkf]

Expected behaviour

Following steps below, GUI should not be blocked, but just show a "not allowed" cursor while the drag-drop target is invalid.

Better, it should also be possible to drag-drop any selection from Engrampa to any target that accepts drag-drop from a file manager.

Actual behaviour

Following the steps below, GUI shows a "drag copy" cursor when the invalid d'n'd target is hovered and a dialog appears You don't have the right permissions to extract archives in the folder "" but the normal cursor is never reactivated, despite the cursor responding to mouse movements, and the GUI remains blocked to mouse and keyboard actions. Releasing the dragging mouse button, mouse clicks, ESC, etc, have no effect.

Switching to a separate console session (c-a-F6), pkill engrampa, and switching back (c-a-F7) unblocks the GUI. Also, the dialog can be closed with <Alt+F4>, but that has no other effect. It's possible to switch to a previously opened Xfce Terminal running bash with <Alt+Tab>; in the Terminal <Space> and <Enter>, and the plain arrow keys, are blocked but <Tab> and <Ctrl+j> can be used to invoke the pkill command.

Probably any entry in the PCManFM Places list behaves similarly. The Places list in Thunar doesn't. Also probably, the underlying issue could be a defect in PCManFM, but it shouldn't be possible for that to block the GUI. Eg, drag-dropping an item from Thunar to the PCManFM Places list doesn't have the same result (but/and that can be a valid action).

Steps to reproduce the behaviour

Installed:
MX Linux 23.2, kernel 6.1.0-18-686-pae, xfce4 4.18, xfwm4 4.18.0-1, Engrampa 1.26.0-1+deb12u2 (hurrah, no CSD!), pcmanfm 1.3.2.1

1. Plug in FAT32 USB stick.
2. Open PCManFM and select some folder on the local disk containing an archive file
3. Show the Places sidebar in pcmanfm: the USB device should be shown.
4. Open the archive in Engrampa
5. Select a file in the archive from the file list pane.
6. Drag the file towards the pcmanfm window: a file details strip becomes attached to the "drag" cursor.
7. Move the drag cursor over the USB filesystem in the Places list
8. The "drag" cursor (for me it was a black one-fingered hand, but would depend on theming) instantly gets a "drag copy" + and a dialog (as above) opens.
9. The "drag_copy" cursor does not change as you move the cursor away from the invalid target, nor if you abandon the d'n'd by releasing the button.
10. The dialog can't be closed with its Close button although <Alt+F4> works.
11. Despite any of these, the "drag copy" cursor remains and the GUI remains blocked to mouse and keyboard actions (until the engrampa process is killed by other means).

MATE general version

Not used in MATE

Package version

1.26.0-1+deb12u2

Linux Distribution

MX Linux 23.2

Link to bugreport of your Distribution (requirement)

https://bugs.mxlinux.org/show_bug.cgi?id=783

[dirkf]

Related: #183

From linked distro issue:

... this is a not a PCManFM issue even if the PCManFM code might be wrong [but see https://github.com/lxde/libfm/issues/45#issuecomment-1304250545]. Regardless of the drop target, the GUI code should not hang. The cursor is captured for the drag-drop but never released, presumably because the drag-drop handler has crashed without releasing it. There is a timeout and/or exception handler missing somewhere. ...

I believe that this is an issue with either GTK or the way applications, including engrampa, xarchiver and Firefox, are using it.

[zhuyaliang]

@dirkf Please test if the problem is resolved

[dirkf]

If you have a Debian x86 build that matches this dependency output for 1.26.0-1+deb12u2, I can test it as a drop-in.

ldd $(which engrampa)

$ engrampa --version
Engrampa Archive Manager 1.26.0
$ ldd $(which engrampa)
	linux-gate.so.1 (0xb7f4b000)
	libSM.so.6 => /lib/i386-linux-gnu/libSM.so.6 (0xb7e98000)
	libICE.so.6 => /lib/i386-linux-gnu/libICE.so.6 (0xb7e7b000)
	libgtk-3.so.0 => /lib/i386-linux-gnu/libgtk-3.so.0 (0xb7400000)
	libgdk-3.so.0 => /lib/i386-linux-gnu/libgdk-3.so.0 (0xb7d5d000)
	libpango-1.0.so.0 => /lib/i386-linux-gnu/libpango-1.0.so.0 (0xb7390000)
	libcairo.so.2 => /lib/i386-linux-gnu/libcairo.so.2 (0xb723f000)
	libgdk_pixbuf-2.0.so.0 => /lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0 (0xb720c000)
	libjson-glib-1.0.so.0 => /lib/i386-linux-gnu/libjson-glib-1.0.so.0 (0xb71db000)
	libgio-2.0.so.0 => /lib/i386-linux-gnu/libgio-2.0.so.0 (0xb6e00000)
	libgobject-2.0.so.0 => /lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb7175000)
	libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb6caa000)
	libmagic.so.1 => /lib/i386-linux-gnu/libmagic.so.1 (0xb7145000)
	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7040000)
	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6a00000)
	libuuid.so.1 => /lib/i386-linux-gnu/libuuid.so.1 (0xb7d51000)
	libbsd.so.0 => /lib/i386-linux-gnu/libbsd.so.0 (0xb6c93000)
	libgmodule-2.0.so.0 => /lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xb7d4b000)
	libpangocairo-1.0.so.0 => /lib/i386-linux-gnu/libpangocairo-1.0.so.0 (0xb7030000)
	libharfbuzz.so.0 => /lib/i386-linux-gnu/libharfbuzz.so.0 (0xb68de000)
	libpangoft2-1.0.so.0 => /lib/i386-linux-gnu/libpangoft2-1.0.so.0 (0xb6c78000)
	libfontconfig.so.1 => /lib/i386-linux-gnu/libfontconfig.so.1 (0xb688b000)
	libfribidi.so.0 => /lib/i386-linux-gnu/libfribidi.so.0 (0xb6c5c000)
	libcairo-gobject.so.2 => /lib/i386-linux-gnu/libcairo-gobject.so.2 (0xb6c53000)
	libatk-1.0.so.0 => /lib/i386-linux-gnu/libatk-1.0.so.0 (0xb6c2a000)
	libepoxy.so.0 => /lib/i386-linux-gnu/libepoxy.so.0 (0xb677a000)
	libXi.so.6 => /lib/i386-linux-gnu/libXi.so.6 (0xb6765000)
	libX11.so.6 => /lib/i386-linux-gnu/libX11.so.6 (0xb6613000)
	libatk-bridge-2.0.so.0 => /lib/i386-linux-gnu/libatk-bridge-2.0.so.0 (0xb65d4000)
	libXfixes.so.3 => /lib/i386-linux-gnu/libXfixes.so.3 (0xb65cc000)
	libxkbcommon.so.0 => /lib/i386-linux-gnu/libxkbcommon.so.0 (0xb6582000)
	libwayland-client.so.0 => /lib/i386-linux-gnu/libwayland-client.so.0 (0xb6573000)
	libwayland-cursor.so.0 => /lib/i386-linux-gnu/libwayland-cursor.so.0 (0xb656a000)
	libwayland-egl.so.1 => /lib/i386-linux-gnu/libwayland-egl.so.1 (0xb6565000)
	libXext.so.6 => /lib/i386-linux-gnu/libXext.so.6 (0xb654f000)
	libXcursor.so.1 => /lib/i386-linux-gnu/libXcursor.so.1 (0xb6542000)
	libXdamage.so.1 => /lib/i386-linux-gnu/libXdamage.so.1 (0xb653d000)
	libXcomposite.so.1 => /lib/i386-linux-gnu/libXcomposite.so.1 (0xb6538000)
	libXrandr.so.2 => /lib/i386-linux-gnu/libXrandr.so.2 (0xb6529000)
	libXinerama.so.1 => /lib/i386-linux-gnu/libXinerama.so.1 (0xb6524000)
	libthai.so.0 => /lib/i386-linux-gnu/libthai.so.0 (0xb6517000)
	libpixman-1.so.0 => /lib/i386-linux-gnu/libpixman-1.so.0 (0xb6466000)
	libfreetype.so.6 => /lib/i386-linux-gnu/libfreetype.so.6 (0xb6396000)
	libpng16.so.16 => /lib/i386-linux-gnu/libpng16.so.16 (0xb6359000)
	libxcb-shm.so.0 => /lib/i386-linux-gnu/libxcb-shm.so.0 (0xb6354000)
	libxcb.so.1 => /lib/i386-linux-gnu/libxcb.so.1 (0xb6326000)
	libxcb-render.so.0 => /lib/i386-linux-gnu/libxcb-render.so.0 (0xb6317000)
	libXrender.so.1 => /lib/i386-linux-gnu/libXrender.so.1 (0xb6309000)
	libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb62ec000)
	libjpeg.so.62 => /lib/i386-linux-gnu/libjpeg.so.62 (0xb625c000)
	libmount.so.1 => /lib/i386-linux-gnu/libmount.so.1 (0xb61e9000)
	libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb61b6000)
	libffi.so.8 => /lib/i386-linux-gnu/libffi.so.8 (0xb61ac000)
	libpcre2-8.so.0 => /lib/i386-linux-gnu/libpcre2-8.so.0 (0xb610d000)
	liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xb60d7000)
	libbz2.so.1.0 => /lib/i386-linux-gnu/libbz2.so.1.0 (0xb60c5000)
	/lib/ld-linux.so.2 (0xb7f4d000)
	libmd.so.0 => /lib/i386-linux-gnu/libmd.so.0 (0xb60b6000)
	libgraphite2.so.3 => /lib/i386-linux-gnu/libgraphite2.so.3 (0xb6089000)
	libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb605d000)
	libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6056000)
	libatspi.so.0 => /lib/i386-linux-gnu/libatspi.so.0 (0xb6019000)
	libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0xb5fb8000)
	libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb5fb3000)
	libdatrie.so.1 => /lib/i386-linux-gnu/libdatrie.so.1 (0xb5fa8000)
	libbrotlidec.so.1 => /lib/i386-linux-gnu/libbrotlidec.so.1 (0xb5f9a000)
	libXau.so.6 => /lib/i386-linux-gnu/libXau.so.6 (0xb5f95000)
	libXdmcp.so.6 => /lib/i386-linux-gnu/libXdmcp.so.6 (0xb5f8e000)
	libblkid.so.1 => /lib/i386-linux-gnu/libblkid.so.1 (0xb5f2c000)
	libsystemd.so.0 => /lib/i386-linux-gnu/libsystemd.so.0 (0xb5e55000)
	libbrotlicommon.so.1 => /lib/i386-linux-gnu/libbrotlicommon.so.1 (0xb5e32000)
	libcap.so.2 => /lib/i386-linux-gnu/libcap.so.2 (0xb5e25000)
	libgcrypt.so.20 => /lib/i386-linux-gnu/libgcrypt.so.20 (0xb5d1a000)
	libzstd.so.1 => /lib/i386-linux-gnu/libzstd.so.1 (0xb5c62000)
	liblz4.so.1 => /lib/i386-linux-gnu/liblz4.so.1 (0xb5c3c000)
	libgpg-error.so.0 => /lib/i386-linux-gnu/libgpg-error.so.0 (0xb5c12000)
$

[zhuyaliang]

@dirkf Sorry, I don't use Debian. Can you manually compile and test it?

[dirkf]

Unfortunately, the machine with this set-up only has enough build functionality to update kernel drivers. Maybe you can propose the patch to the Debian maintainers?

Also, perhaps the same patch applies to File Roller and its other forks?

Current Debian versions are

• bookworm (stable) 1.26.0-1+deb12u2
• sid (unstable) 1.26.2-4

[zhuyaliang]

@dirkf @cwendling lxde/libfm#103

[dirkf]

If the solution in lxde/libfm#45 (comment) works, the bug hits all three targets.

In PCManFM, the immediate issue can be solved by testing for a source widget in src/gtk/fm-places-view.c where gtk_drag_dest_find_target() hangs if the drag_context has a valid source window (as returned by gdk_drag_context_get_source_window()) but no valid source widget (as returned by gdk_window_get_user_data()).

The next immediate issue is that engrampa is allowing GTK drag'n'drop from a source window with no associated GTK widget (or something has destroyed that association). This sounds like something that would, or should, be forbidden by the API documentation.

Finally GTK is causing the underlying issue through allowing gtk_drag_dest_find_target() to hang the UI when its drag_context has a source window with no source widget. Looking at https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.24/gtk/gtkdragdest.c, where the programmers strangely eschew the for loops that would make the code clearer, there are two linked list traversals in gtk_drag_dest_find_target(), and one in gtk_drag_get_source_widget() called by it earlier, that could fail to terminate if there is no null pointer at the end of the list. But there's no obvious way that a window with no widget (which seems to be envisaged) would cause that.