Application freeze when drag-extracting to "nowhere" (no Desktop Environment)

[aphirst]

Expected behaviour

Nothing happens, return to application, try again

Actual behaviour

Application freezes, steals control of mouse, must be xkilled or killalled. Usually the latter is necessary, since it becomes unable to select a terminal window OR press Enter/Space in e.g. an Alt+F2 dialog (e.g. gmrun)

Steps to reproduce the behaviour

Not be running a DE (in my case just Openbox)
Open any archive
Select a file or files, drag out of window
Drag onto "desktop" (no file manager running "as desktop") or onto some non-file-aware application window

MATE general version

N/A

Package version

1.18.2, has done this as long as I can remember (at least 2 years, not sure which version)

Linux Distribution

Arch

Link to downstream report of your Distribution

[aphirst]

Issue is still present in 1.18.3.

[lukefromdc]

I just found that in 1.20 (git) and in MATE with icons on the desktop turned off, this does not occur: Instead, the dragged icon just "flies back" to the Engrampa window it was dragged from, and the mouse remains responsive and can be used normally. This is on Debian Unstable, with MATE 1.19 and 1.20 packages as currently available from git master

[aphirst]

@lukefromdc Are you able to try this in a different window manager session, without mate's (or any other) session manager (assuming it's analogous to xfce/lxde/gnome etc.) running?

[lukefromdc]

Same behavior in an IceWM session with nothing set up to manage the desktop, though I do use mate-settings-daemon in that for theme control. I don't have anything lighter installed

[aphirst]

My personal (entirely uneducated) suspicion is that mate-settings-daemon (or these daemons in general) does/provides something that engrampa hard-assumes is there, and hard-fails when it isn't. To test with mate-settings-daemon I'd need to pull all the mate deps, but are you able to test once more in a "clean" x session with literally just the WM running?

[lukefromdc]

NO, I don't have any bare sessions set up like that-and ANY session change test forces me to kill my browser session which is in RAM and set aside all other work. Leaving this for other devs to test

[aphirst]

Fair enough. Will wait then for other feedback.

[aphirst]

Issue still present in 1.20.0

When it happens, I lose the ability to click, or to press either Return or Space (meaning I have to killall engrampa in a separate tty, since I can't properly enter killall or xkill within that X session), and there's an error message:

(Where obviously I can't click "close" because clicking doesn't work.)

[vkareh]

I can confirm this is happening with both Engrampa and GNOME's file-roller. It happens whenever a file is dragged from engrampa to PCManFM, while the dragged icon passes over the left-side panel of said file manager.

Seems very niche, and it's either PCManFM's fault or something in the original file-roller code (and engrampa just inherited it)

[vkareh]

Okay, I've decided that I'm closing this bug (sorry @aphirst). I just tested using Xarchiver with PCManFM inside a TWM session and I could still reproduce the issue. So this is definitely not a MATE/Engrampa issue. Maybe file the bug against LXDE or directly to PCManFM.

[kn00tcn]

dragging to pcmanfm's files pane works, only the bookmarks pane doesnt since it's not made for pasting (except dirs)

i'm trying to find out what else lets you drag into a paste operation, file-roller seems to act similar with the pcmanfm pane, alt+f4 on engrampa/file-roller sometimes works to get out of it, other focus stealing methods also may work (like compiz>scale>window picker, or mousewheeling any titlebar)

what if it's something to do with xorg or gtk?

[vkareh]

From what I remember looking at the PCManFM source code, it seems like it was an issue in the handling of the XEvent for dragging a for over the side pane

[kn00tcn]

nothing bad happens when dragging from other apps like browser or image viewer, though they dont do anything when dropping onto the files pane either (actually, i couldnt get engrampa to extract by dropping anyway)

[aphirst]

I added an additional comment to pcmanfm's bug tracker, but don't have a response yet.

https://sourceforge.net/p/pcmanfm/bugs/572/

To confirm, I still get the issue with pcmanfm 1.3.0 with libfm 1.3.0.2 - dragging into pcmanfm works if you're careful and drag from the Right Hand Side; if you end up dragging over the Shortcuts area on the left it causes engrampa to freeze.

[CasperVector]

Just in case anyone is interested, I have pasted a patch in lxde/libfm#45.

[dirkf]

See also #515 (comment) and linked issue https://bugs.mxlinux.org/show_bug.cgi?id=783.

[lukefromdc]

The linked comments gave a better understanding of this ("blocks the GUI" could be anything), I've had issues in Caja with a bad drag and drop making the cursor unresponsive, and staying at one of the cursor icons other than the arrow. The description that the cursor is grabbed and not released describes what I've had in caja, releasing the cursor requires restarting caja when this happens. The fact that this is occuring in multiple DEs and multiple programs, having in common GTK3. Relevent comment at https://bugs.mxlinux.org/show_bug.cgi?id=783#c2 is: "But as I pointed out, this is a not a PCManFM issue even if the PCManFM code might be wrong (which hasn't been established). 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. So this is an issue with one or more of * Xfce - the same thing happens with LXDE 7Ubunt1, PCManFM 1.2.4 and xarchiver 1.5.4.22, but maybe the same/similar code is being used * some underlying GUI framework library, GTK (https://docs.gtk.org/gtk4/drag-and-drop.html) probably (to do: test with PCManFM-QT) * the Desktop specification being implemented * how a wide variety of applications including archiver managers and Firefox are implementing that specification." Note that we do not use GTK4, Firefox does not use GTK4 (and was one of the reasons for branching GTK4 when breaking changes were merged just after their GTK3 transition), presumably PCManFM never will. Thus GTK4 reference should be to GTK 3. I agree this is a much bigger problem than just one program. Whereever it is coming from, it could cause users to kill the xserver or even power-cycle if they don't know now to get out of it, losing all their unsaved work in the process

[dirkf]

The GTK3 documentation doesn't appear to have a matching page, but asking G for gtk3 drag-and-drop produces results that look as if they should be useful. I claim no expertise here, though I may once have played with equivalent APIs in Win32/COM.

This might enable someone to interpret the linked page for GTK3.

Among the reasons why PCManFM maintenance might have been unresponsive (and the suggested patch not applied) for the last several years, I see that one of the more active devs had an email address ending in .kiev.ua.