STR #3399: X11 Drag and drop issue when displaying popup on recept of payload

STR #3399

Application:	FLTK Library
Status:	5 - New
Priority:	4 - High, e.g. key functionality not working
Scope:	2 - Specific to an operating system
Subsystem:	X11
Summary:	X11 Drag and drop issue when displaying popup on recept of payload
Version:	1.4.0
Created By:	chris
Assigned To:	Unassigned
Fix Version:	Unassigned
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Post File

#1	chris 09:03 Sep 09, 2017

dnd_internal.txt
1k

#2	chris 09:03 Sep 09, 2017

dnd_external.txt
1k

Trouble Report Comments:

Post Text

#1	chris 09:03 Sep 09, 2017

As requested, opening a STR from the discussion "Drag and drop issue - [General Use]" on fltkgeneral: https://groups.google.com/forum/#!topic/fltkgeneral/rTIynLKsEhs Short summary: The OP (Nimday Satria) tried to display a message in the handle() routine of the "howto-drag-and-drop" example when the FL_PASTE event was delivered. This resulted in a deadlock. I found a patch for that, which is attached as "dnd_internal.txt". First resume from Albrecht Schlosser on the patch was (citing from thread): "I think this solution is correct and that there are no side effects to be expected. Basically the *only* thing that is changed is that the instruction fl_local_grab = 0; is executed right before calling Fl::paste() instead of (or, to be precise: additional to) right after Fl::paste(). This enables normal event processing during FL_PASTE whereas the code as it is now would ignore all events during FL_PASTE processing. AFAICT this is what happens: During DND operations fl_local_grab, which is used only under X, contains a function pointer to the static function grabfunc() which makes the event delivery *ignore* all events except mouse button release (FL_RELEASE) [1]. If grabfunc() is called with a FL_RELEASE event it sets Fl::pushed(0), which in turn makes the DND loop terminate and deliver the payload with Fl::paste() -- after asking the target window/widget if it accepts it with FL_DND_RELEASE -- otherwise the payload is ignored. Since we are here at the point where Fl::paste() is called we know that the mouse button has already been released and we can safely clear fl_local_grab to enable normal event processing during delivery of the DND payload with the FL_PASTE event." --- Later Albrecht discovered, that dragging from some external applications (CodeLite in this case) into the example program led to hanging key and mouse in the external application after the example popped up the message. I found a patch for this too, which I attach as "dnd_external.txt". Citing my resume on this patch: "I found out, that the drop from CodeLite (or any other external source) runs through Fl_x.cxx line 1413: int retval = fl_selection_requestor->handle(Fl::e_number = FL_PASTE); Immediately after is a code section flagged by a comment about sending the XdndFinished message here or maybe earlier. I assume, that CodeLite is duly confirming to the protocol and waits for the finished message to arrive, before declaring the drop event done. But if FLTK pops up a message it will reach the code that sends this message only *after* the popup is dismissed and then it may be already too late for CodeLite. Other applications perhaps are more tolerant about the arrival of the XdndFinished event. However these are just educated guesses.. But they lead to the thought, that maybe FLTK could send the XdndFinished message *before* doing the paste (just in case the application pops up a message)."

#2	AlbrechtS 04:33 Jan 16, 2023

Chris, hasn't this been fixed? ISTR there was a GitHub issue...

#3	chris 07:48 Jan 16, 2023

> Chris, hasn't this been fixed? ISTR there was a GitHub issue... I don't think so. The "howto-drag-and-drop" example has been changed meanwhile to include a comment *not* to open a message directly in the FL_PUSHED callback, but to use a timer (example has been added too) instead. If I deliverately change the code in this exanple to show a message immediately (like the OP did) then the hang still occurs. Applying my fix 'dnd_internal.txt' and the hang does not occur. I didn't check the other case, for which 'dnd_external.txt' was for.

#4	chris 07:49 Jan 16, 2023

I meant of course ".. in the FL_PASTE" callback ...

#5	AlbrechtS 08:00 Jan 16, 2023

Thanks for the quick feedback. I'm working on commenting, fixing, and hopefully closing open STR's, and this one rang a bell in my mind (that I'd seen something like that already). If these issues are not yet fixed we need to investigate and fix the issue(s).