[Webkit-unassigned] [Bug 218462] New: REGRESSION(r261570): [GTK] Drag of unknown type aborted on motion above WebView under X11

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=218462

            Bug ID: 218462
           Summary: REGRESSION(r261570): [GTK] Drag of unknown type
                    aborted on motion above WebView under X11
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcatanzaro at gnome.org
                CC: bugs-noreply at webkitgtk.org

Under X11, drag an email in Evolution **through a web view** to the folders treeview sidebar.

Expected behavior: you can drag an email to the sidebar

Actual behavior: if your drag traverses the web view, the drag is cancelled

For some reason, under X11 we receive only two drag-motion events from GTK, both immediately after the drag begins. Then no more events until drag leave and drag drop. Whereas under Wayland, we receive a huge number of drag-motion events, once every time the cursor moves from one pixel to the next, as expected.

Complication: our drag-data-received signal handler is supposed to tell GTK whether the drag will be accepted or not by calling gdk_drag_status(). But this is impossible to do, since we have to pass the drag data to the web process, so we do it later in DropTarget::didPerformAction, even though that's not really permitted by the documentation of drag-data-received. That might be related.

Prior to this regression, we receive *no* drag-motion events, which is extremely confusing (WTF?). In particular, neither webkitWebViewBaseDragMotion nor DragAndDropHandler::dragMotion is ever called. I wondered if some other drag-motion handler was handling it first, but no drag-motion callback in evolution itself is called either. That's confusing, but it suggests this workaround:

diff --git a/Source/WebKit/UIProcess/API/gtk/DropTargetGtk3.cpp b/Source/WebKit/UIProcess/API/gtk/DropTargetGtk3.cpp
index 388dec07db2e..13013aee14d8 100644
--- a/Source/WebKit/UIProcess/API/gtk/DropTargetGtk3.cpp
+++ b/Source/WebKit/UIProcess/API/gtk/DropTargetGtk3.cpp
@@ -62,7 +62,7 @@ DropTarget::DropTarget(GtkWidget* webView)
             drop.accept(time);
         } else if (drop.m_drop == context)
             drop.update({ x, y }, time);
-        return TRUE;
+        return FALSE;
     }), this);

     g_signal_connect(m_webView, "drag-leave", G_CALLBACK(+[](GtkWidget*, GdkDragContext* context, guint time, gpointer userData) {

That means "reject all drags," so it's not a very good solution, but it does avoid this bug.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201102/9a4a9f81/attachment.htm>