STR #3399

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #3399

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

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 chris
09:03 Sep 09, 2017
#2 chris
09:03 Sep 09, 2017
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#1 chris
09:03 Sep 09, 2017
As requested, opening a STR from the discussion "Drag and drop issue - [General Use]" on fltkgeneral:!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

   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).
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2023 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.