[Webkit-unassigned] [Bug 218562] New: [GTK][Regression][2.30] Application cannot override drag&drop callbacks

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 4 06:08:27 PST 2020


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

            Bug ID: 218562
           Summary: [GTK][Regression][2.30] Application cannot override
                    drag&drop callbacks
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mcrha at redhat.com
                CC: bugs-noreply at webkitgtk.org

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.

-- 
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/20201104/40e83aca/attachment.htm>


More information about the webkit-unassigned mailing list