Resolves: tdf#132477 use "cancel" on GdkDragContext
gtk_drag_cancel gave trouble as previously described and GDK_KEY_Escape was a
placebo which didn't do anything seeing as it wasn't applied by
gtk_main_do_event to the drag GDK_KEY_Escape handler
Change-Id: I66f6e04ded12144a33a38504f5bfc1cad7807bb9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93673
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
diff --git a/vcl/unx/gtk3/gtk3gtkinst.cxx b/vcl/unx/gtk3/gtk3gtkinst.cxx
index 20bf659..0a99fe7 100644
--- a/vcl/unx/gtk3/gtk3gtkinst.cxx
+++ b/vcl/unx/gtk3/gtk3gtkinst.cxx
@@ -3075,14 +3075,9 @@ IMPL_LINK(GtkInstanceWidget, async_drag_cancel, void*, arg, void)
// doesn't seem to work as hoped for (though under wayland all is well).
// Under X the next (allowed) drag effort doesn't work to drop anything,
// but a then repeated attempt does.
// Sending ESC to get gtk to cancel the drag for us does work as hoped for.
GdkEvent *event = GtkSalFrame::makeFakeKeyPress(m_pWidget);
event->key.keyval = GDK_KEY_Escape;
gtk_main_do_event(event);
gdk_event_free(event);
// emitting cancel to get gtk to cancel the drag for us does work as hoped for.
g_signal_emit_by_name(context, "cancel", 0, GDK_DRAG_CANCEL_USER_CANCELLED);
// Retain this gtk_drag_cancel belt-and-braces call anyway
gtk_drag_cancel(context);
g_object_unref(context);
}
