In attachment 512731 [details], drag div A and drop onto div B (which doesn't accept the
drop). Expected order of events is dragstart, dragenter, dragleave, dragend.
(See also bug 497498 comment 26.)
A GTK drag source sends the leave message to the destination before the
drag-end or drag-failed signal on the source widget, but the leave message
goes via the X server, and so doesn't get processed at least until the event
loop is run again.
This behaves correctly according to W3C spec, and a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=619703
Sorry, reading comprehension fail.
This is NOT a duplicate of 619703, which has to do with dragenter/dragleave (destinations). This ticket has to do with dragleave (destination) vs. dragend (source) and I'm not sure what the spec says regarding these.
Created attachment 607431 [details] [diff] [review]
schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order
This patch applies on top of those in bug 497498.
The bug reported here happens when the target will not accept the drop so GTK gives us a source drag-end signal without a target drop.
RunScheduledTask will dispatch any necessary leave event.
It would be good to write a test here.
Perhaps a unit test could dispatch fake GdkEvents to the event loop.
We may be able to use gtk_grab_get_current() to get the correct GdkWindow.
Maybe that's not worth the effort.
Created attachment 609616 [details] [diff] [review]
part 1: don't start a new source drag session until the previous has completed
There is an existing possibility that InvokeDragSession could be called before
a destination has replied to indicate that it has received a drop, and so
EndDragSession has not yet been called.
The next patch here will run EndDragSession off an event, which could make this
a little more likely. The ideal fix is probably to have a separate drag
session object for each drag, but the simple defence is to avoid starting a new
session until the previous has completed.
Created attachment 609618 [details] [diff] [review]
part 2: schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order v2
There is a modification from the previous version to ensure that EndDragSession happens.
Created attachment 609991 [details] [diff] [review]
part 2: schedule event dispatch in response to GTK drag end signals to avoid running the event loop at unexpected times and dispatch leave events in the right order v3
Should also ensure that SourceEndDragSession doesn't run twice.
A drag-end signal follows a drag-failed signal.