diff options
authorCaolán McNamara <>2020-05-07 19:41:25 +0100
committerCaolán McNamara <>2020-05-08 10:10:02 +0200
commitea6a978d873c5320d3cc2526f97636f815efde06 (patch)
parentb6ad72a34c150df18905e47e588fd35c400dd6b9 (diff)
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: Tested-by: Jenkins Reviewed-by: Caolán McNamara <>
1 files changed, 3 insertions, 8 deletions
diff --git a/vcl/unx/gtk3/gtk3gtkinst.cxx b/vcl/unx/gtk3/gtk3gtkinst.cxx
index 20bf6596cd77..0a99fe737316 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);
- // Retain this gtk_drag_cancel belt-and-braces call anyway
- gtk_drag_cancel(context);
+ // 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);