Bug 218562 - [GTK][Regression][2.30] Application cannot override drag&drop callbacks
Summary: [GTK][Regression][2.30] Application cannot override drag&drop callbacks
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
: 216828 218163 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-11-04 06:08 PST by Milan Crha
Modified: 2020-11-06 03:29 PST (History)
9 users (show)

See Also:


Attachments
proposed patch (3.83 KB, patch)
2020-11-04 09:01 PST, Milan Crha
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Crha 2020-11-04 06:08:27 PST
Downstream bug report:
https://gitlab.gnome.org/GNOME/evolution/-/issues/1200

When dragging files from Nautilus above a message body in Evolutions' composer window (which is a WebKitWebView), the composer code listens for "drag-drop" and other signals and it can override what to do when certain types are included in those provided by the source widget/application. These callbacks are installed in the composer's GObject::constructed() method, after this method calls parent's constructed(). I think, and only think, that glib is processing multiple callbacks in the opposite order than in which they had been connected (+/- _after function/flag).

It looks like WebKitGTK adds its callbacks after those which Evolution added, thus they are called first and they pick text/plain format, which is the URI of the file, not the text/uri-list, which handles Evolution on its own.

I can (kind of) confirm my theory, because when I postpone signal connect in Evolution by one second it works as expected again, callbacks from the Evolution are called before callbacks from the WebKitGTK.

Eventually, this can be related to bug #218462, even I'm able to reproduce this regardless whether running Wayland or X11.
Comment 1 Milan Crha 2020-11-04 09:01:15 PST
Created attachment 413169 [details]
proposed patch

This fixes it for me. Three changes are included, all are needed:

1) use g_signal_connect_after(), thus the descendants can get before that callback, as it used to be when the d&d callbacks had been assigned as GtkWidgetClass members;

2) update the inner m_drop context whenever it's different from the passed-in context in the "drag-motion" handler, otherwise one cannot drag the second time, because the "drag-leave" was not called (it is not called here);

3) in the DropTarget::didPerformAction() always call gdk_drag_status(), otherwise the drag can look like being frozen.
Comment 2 EWS Watchlist 2020-11-04 09:02:04 PST
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment 3 Michael Catanzaro 2020-11-04 09:20:06 PST
(In reply to Milan Crha from comment #1)
> 1) use g_signal_connect_after(), thus the descendants can get before that
> callback, as it used to be when the d&d callbacks had been assigned as
> GtkWidgetClass members;

Good.

> 2) update the inner m_drop context whenever it's different from the
> passed-in context in the "drag-motion" handler, otherwise one cannot drag
> the second time, because the "drag-leave" was not called (it is not called
> here);

Odd... seems like drag-leave ought to be called?

> 3) in the DropTarget::didPerformAction() always call gdk_drag_status(),
> otherwise the drag can look like being frozen.

OK, good.
Comment 4 Milan Crha 2020-11-05 01:31:12 PST
(In reply to Michael Catanzaro from comment #3)
> Odd... seems like drag-leave ought to be called?

Right, it should be called, according to the gtk+ documentation, but it's not called for some reason. I didn't try to figure out why. In any case, the system can have "running" only a single drag operation in the time, thus the idea of always updating the m_drop when it doesn't match the current context makes sense.
Comment 5 Michael Catanzaro 2020-11-05 06:19:32 PST
Comment on attachment 413169 [details]
proposed patch

OK, all this makes sense to me. I'm not giving cq+ yet, though, because Carlos Garcia will want to review this before it lands, so let's allow some time for that.

If we commit this, we should also remember to close bug #218462.
Comment 6 Carlos Garcia Campos 2020-11-06 00:59:02 PST
Comment on attachment 413169 [details]
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=413169&action=review

> Source/WebKit/UIProcess/API/gtk/DropTargetGtk3.cpp:59
> -    g_signal_connect(m_webView, "drag-motion", G_CALLBACK(+[](GtkWidget*, GdkDragContext* context, gint x, gint y, guint time, gpointer userData) -> gboolean {
> +    g_signal_connect_after(m_webView, "drag-motion", G_CALLBACK(+[](GtkWidget*, GdkDragContext* context, gint x, gint y, guint time, gpointer userData) -> gboolean {

I guess this is not needed in GTK4, because apps wanting to override this can use the capture phase on GtkDropTargetAsync?
Comment 7 Carlos Garcia Campos 2020-11-06 01:00:18 PST
*** Bug 218163 has been marked as a duplicate of this bug. ***
Comment 8 EWS 2020-11-06 01:09:35 PST
Committed r269505: <https://trac.webkit.org/changeset/269505>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 413169 [details].
Comment 9 Milan Crha 2020-11-06 01:16:42 PST
(In reply to Carlos Garcia Campos from comment #6)
> I guess this is not needed in GTK4, because apps wanting to override this
> can use the capture phase on GtkDropTargetAsync?

I do not know gtk4 at all, but my quick check on what WebKit does there didn't show anything relevant (the signals being attached to are very different from those in gtk3).
Comment 10 Carlos Garcia Campos 2020-11-06 03:29:58 PST
*** Bug 216828 has been marked as a duplicate of this bug. ***