<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>218562</bug_id>
          
          <creation_ts>2020-11-04 06:08:27 -0800</creation_ts>
          <short_desc>[GTK][Regression][2.30] Application cannot override drag&amp;drop callbacks</short_desc>
          <delta_ts>2020-11-06 03:29:58 -0800</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>WebKitGTK</component>
          <version>Other</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Milan Crha">mcrha</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>amarok</cc>
    
    <cc>berto</cc>
    
    <cc>bugs-noreply</cc>
    
    <cc>cgarcia</cc>
    
    <cc>ews-watchlist</cc>
    
    <cc>gustavo</cc>
    
    <cc>ht990332</cc>
    
    <cc>mcatanzaro</cc>
    
    <cc>nekohayo</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>1704382</commentid>
    <comment_count>0</comment_count>
    <who name="Milan Crha">mcrha</who>
    <bug_when>2020-11-04 06:08:27 -0800</bug_when>
    <thetext>Downstream bug report:
https://gitlab.gnome.org/GNOME/evolution/-/issues/1200

When dragging files from Nautilus above a message body in Evolutions&apos; composer window (which is a WebKitWebView), the composer code listens for &quot;drag-drop&quot; 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&apos;s GObject::constructed() method, after this method calls parent&apos;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&apos;m able to reproduce this regardless whether running Wayland or X11.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1704455</commentid>
    <comment_count>1</comment_count>
      <attachid>413169</attachid>
    <who name="Milan Crha">mcrha</who>
    <bug_when>2020-11-04 09:01:15 -0800</bug_when>
    <thetext>Created attachment 413169
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&amp;d callbacks had been assigned as GtkWidgetClass members;

2) update the inner m_drop context whenever it&apos;s different from the passed-in context in the &quot;drag-motion&quot; handler, otherwise one cannot drag the second time, because the &quot;drag-leave&quot; 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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1704456</commentid>
    <comment_count>2</comment_count>
    <who name="EWS Watchlist">ews-watchlist</who>
    <bug_when>2020-11-04 09:02:04 -0800</bug_when>
    <thetext>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</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1704462</commentid>
    <comment_count>3</comment_count>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2020-11-04 09:20:06 -0800</bug_when>
    <thetext>(In reply to Milan Crha from comment #1)
&gt; 1) use g_signal_connect_after(), thus the descendants can get before that
&gt; callback, as it used to be when the d&amp;d callbacks had been assigned as
&gt; GtkWidgetClass members;

Good.

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

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

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

OK, good.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1704781</commentid>
    <comment_count>4</comment_count>
    <who name="Milan Crha">mcrha</who>
    <bug_when>2020-11-05 01:31:12 -0800</bug_when>
    <thetext>(In reply to Michael Catanzaro from comment #3)
&gt; Odd... seems like drag-leave ought to be called?

Right, it should be called, according to the gtk+ documentation, but it&apos;s not called for some reason. I didn&apos;t try to figure out why. In any case, the system can have &quot;running&quot; only a single drag operation in the time, thus the idea of always updating the m_drop when it doesn&apos;t match the current context makes sense.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1704836</commentid>
    <comment_count>5</comment_count>
      <attachid>413169</attachid>
    <who name="Michael Catanzaro">mcatanzaro</who>
    <bug_when>2020-11-05 06:19:32 -0800</bug_when>
    <thetext>Comment on attachment 413169
proposed patch

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

If we commit this, we should also remember to close bug #218462.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1705156</commentid>
    <comment_count>6</comment_count>
      <attachid>413169</attachid>
    <who name="Carlos Garcia Campos">cgarcia</who>
    <bug_when>2020-11-06 00:59:02 -0800</bug_when>
    <thetext>Comment on attachment 413169
proposed patch

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

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

I guess this is not needed in GTK4, because apps wanting to override this can use the capture phase on GtkDropTargetAsync?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1705158</commentid>
    <comment_count>7</comment_count>
    <who name="Carlos Garcia Campos">cgarcia</who>
    <bug_when>2020-11-06 01:00:18 -0800</bug_when>
    <thetext>*** Bug 218163 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1705163</commentid>
    <comment_count>8</comment_count>
    <who name="EWS">ews-feeder</who>
    <bug_when>2020-11-06 01:09:35 -0800</bug_when>
    <thetext>Committed r269505: &lt;https://trac.webkit.org/changeset/269505&gt;

All reviewed patches have been landed. Closing bug and clearing flags on attachment 413169.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1705166</commentid>
    <comment_count>9</comment_count>
    <who name="Milan Crha">mcrha</who>
    <bug_when>2020-11-06 01:16:42 -0800</bug_when>
    <thetext>(In reply to Carlos Garcia Campos from comment #6)
&gt; I guess this is not needed in GTK4, because apps wanting to override this
&gt; can use the capture phase on GtkDropTargetAsync?

I do not know gtk4 at all, but my quick check on what WebKit does there didn&apos;t show anything relevant (the signals being attached to are very different from those in gtk3).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>1705183</commentid>
    <comment_count>10</comment_count>
    <who name="Carlos Garcia Campos">cgarcia</who>
    <bug_when>2020-11-06 03:29:58 -0800</bug_when>
    <thetext>*** Bug 216828 has been marked as a duplicate of this bug. ***</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>413169</attachid>
            <date>2020-11-04 09:01:15 -0800</date>
            <delta_ts>2020-11-06 01:09:36 -0800</delta_ts>
            <desc>proposed patch</desc>
            <filename>wk.patch</filename>
            <type>text/plain</type>
            <size>3925</size>
            <attacher name="Milan Crha">mcrha</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nIGIvU291cmNlL1dlYktpdC9DaGFu
Z2VMb2cKaW5kZXggYjMwNjgwNmJkY2MuLmRkMmJlNjBkYmFkIDEwMDY0NAotLS0gYS9Tb3VyY2Uv
V2ViS2l0L0NoYW5nZUxvZworKysgYi9Tb3VyY2UvV2ViS2l0L0NoYW5nZUxvZwpAQCAtMSwzICsx
LDE2IEBACisyMDIwLTExLTA0ICBNaWxhbiBDcmhhICA8bWNyaGFAcmVkaGF0LmNvbT4KKworICAg
ICAgICBbR1RLXSBBcHBsaWNhdGlvbiBjYW5ub3Qgb3ZlcnJpZGUgZHJhZyZkcm9wIGNhbGxiYWNr
cworICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjE4NTYy
CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBVSVBy
b2Nlc3MvQVBJL2d0ay9Ecm9wVGFyZ2V0R3RrMy5jcHA6CisgICAgICAgIChXZWJLaXQ6OkRyb3BU
YXJnZXQ6OkRyb3BUYXJnZXQpOiBVc2UgZ19zaWduYWxfY29ubmVjdF9hZnRlcigpLCB0aHVzCisg
ICAgICAgIGFueSBkZXNjZW5kYW50cyBjYW4gb3ZlcnJpZGUgdGhlIGNhbGxiYWNrcy4KKyAgICAg
ICAgKFdlYktpdDo6RHJvcFRhcmdldDo6ZGlkUGVyZm9ybUFjdGlvbik6IEFsd2F5cyBjYWxsIGdk
a19kcmFnX3N0YXR1cygpLAorICAgICAgICB0byBoYXZlIGd0aysgbm90aWZpZWQgYWJvdXQgZHJh
ZyBwcm9ncmVzcy4KKwogMjAyMC0xMS0wMyAgU2lodWkgTGl1ICA8c2lodWlfbGl1QGFwcGxlLmNv
bT4KIAogICAgICAgICBTZXQgdXAgYmFzaWMgaW5mcmFzdHJ1Y3R1cmUgZm9yIFNwZWVjaFJlY29n
bml0aW9uCmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L1VJUHJvY2Vzcy9BUEkvZ3RrL0Ryb3BU
YXJnZXRHdGszLmNwcCBiL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL0FQSS9ndGsvRHJvcFRhcmdl
dEd0azMuY3BwCmluZGV4IDNmZDQxMmU4ZjQyLi5lYTIyYmNkODNmMiAxMDA2NDQKLS0tIGEvU291
cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2d0ay9Ecm9wVGFyZ2V0R3RrMy5jcHAKKysrIGIvU291
cmNlL1dlYktpdC9VSVByb2Nlc3MvQVBJL2d0ay9Ecm9wVGFyZ2V0R3RrMy5jcHAKQEAgLTU2LDkg
KzU2LDkgQEAgRHJvcFRhcmdldDo6RHJvcFRhcmdldChHdGtXaWRnZXQqIHdlYlZpZXcpCiAgICAg
ICAgIHN0YXRpY19jYXN0PEdka0RyYWdBY3Rpb24+KEdES19BQ1RJT05fQ09QWSB8IEdES19BQ1RJ
T05fTU9WRSB8IEdES19BQ1RJT05fTElOSykpOwogICAgIGd0a19kcmFnX2Rlc3Rfc2V0X3Rhcmdl
dF9saXN0KG1fd2ViVmlldywgbGlzdC5nZXQoKSk7CiAKLSAgICBnX3NpZ25hbF9jb25uZWN0KG1f
d2ViVmlldywgImRyYWctbW90aW9uIiwgR19DQUxMQkFDSygrW10oR3RrV2lkZ2V0KiwgR2RrRHJh
Z0NvbnRleHQqIGNvbnRleHQsIGdpbnQgeCwgZ2ludCB5LCBndWludCB0aW1lLCBncG9pbnRlciB1
c2VyRGF0YSkgLT4gZ2Jvb2xlYW4geworICAgIGdfc2lnbmFsX2Nvbm5lY3RfYWZ0ZXIobV93ZWJW
aWV3LCAiZHJhZy1tb3Rpb24iLCBHX0NBTExCQUNLKCtbXShHdGtXaWRnZXQqLCBHZGtEcmFnQ29u
dGV4dCogY29udGV4dCwgZ2ludCB4LCBnaW50IHksIGd1aW50IHRpbWUsIGdwb2ludGVyIHVzZXJE
YXRhKSAtPiBnYm9vbGVhbiB7CiAgICAgICAgIGF1dG8mIGRyb3AgPSAqc3RhdGljX2Nhc3Q8RHJv
cFRhcmdldCo+KHVzZXJEYXRhKTsKLSAgICAgICAgaWYgKCFkcm9wLm1fZHJvcCkgeworICAgICAg
ICBpZiAoZHJvcC5tX2Ryb3AgIT0gY29udGV4dCkgewogICAgICAgICAgICAgZHJvcC5tX2Ryb3Ag
PSBjb250ZXh0OwogICAgICAgICAgICAgZHJvcC5tX3Bvc2l0aW9uID0gSW50UG9pbnQoeCwgeSk7
CiAgICAgICAgICAgICBkcm9wLmFjY2VwdCh0aW1lKTsKQEAgLTY3LDE0ICs2NywxNCBAQCBEcm9w
VGFyZ2V0OjpEcm9wVGFyZ2V0KEd0a1dpZGdldCogd2ViVmlldykKICAgICAgICAgcmV0dXJuIFRS
VUU7CiAgICAgfSksIHRoaXMpOwogCi0gICAgZ19zaWduYWxfY29ubmVjdChtX3dlYlZpZXcsICJk
cmFnLWxlYXZlIiwgR19DQUxMQkFDSygrW10oR3RrV2lkZ2V0KiwgR2RrRHJhZ0NvbnRleHQqIGNv
bnRleHQsIGd1aW50IHRpbWUsIGdwb2ludGVyIHVzZXJEYXRhKSB7CisgICAgZ19zaWduYWxfY29u
bmVjdF9hZnRlcihtX3dlYlZpZXcsICJkcmFnLWxlYXZlIiwgR19DQUxMQkFDSygrW10oR3RrV2lk
Z2V0KiwgR2RrRHJhZ0NvbnRleHQqIGNvbnRleHQsIGd1aW50IHRpbWUsIGdwb2ludGVyIHVzZXJE
YXRhKSB7CiAgICAgICAgIGF1dG8mIGRyb3AgPSAqc3RhdGljX2Nhc3Q8RHJvcFRhcmdldCo+KHVz
ZXJEYXRhKTsKICAgICAgICAgaWYgKGRyb3AubV9kcm9wICE9IGNvbnRleHQpCiAgICAgICAgICAg
ICByZXR1cm47CiAgICAgICAgIGRyb3AubGVhdmUoKTsKICAgICB9KSwgdGhpcyk7CiAKLSAgICBn
X3NpZ25hbF9jb25uZWN0KG1fd2ViVmlldywgImRyYWctZHJvcCIsIEdfQ0FMTEJBQ0soK1tdKEd0
a1dpZGdldCosIEdka0RyYWdDb250ZXh0KiBjb250ZXh0LCBnaW50IHgsIGdpbnQgeSwgZ3VpbnQg
dGltZSwgZ3BvaW50ZXIgdXNlckRhdGEpIC0+IGdib29sZWFuIHsKKyAgICBnX3NpZ25hbF9jb25u
ZWN0X2FmdGVyKG1fd2ViVmlldywgImRyYWctZHJvcCIsIEdfQ0FMTEJBQ0soK1tdKEd0a1dpZGdl
dCosIEdka0RyYWdDb250ZXh0KiBjb250ZXh0LCBnaW50IHgsIGdpbnQgeSwgZ3VpbnQgdGltZSwg
Z3BvaW50ZXIgdXNlckRhdGEpIC0+IGdib29sZWFuIHsKICAgICAgICAgYXV0byYgZHJvcCA9ICpz
dGF0aWNfY2FzdDxEcm9wVGFyZ2V0Kj4odXNlckRhdGEpOwogICAgICAgICBpZiAoZHJvcC5tX2Ry
b3AgIT0gY29udGV4dCkgewogICAgICAgICAgICAgZ3RrX2RyYWdfZmluaXNoKGNvbnRleHQsIEZB
TFNFLCBGQUxTRSwgdGltZSk7CkBAIC04NCw3ICs4NCw3IEBAIERyb3BUYXJnZXQ6OkRyb3BUYXJn
ZXQoR3RrV2lkZ2V0KiB3ZWJWaWV3KQogICAgICAgICByZXR1cm4gVFJVRTsKICAgICB9KSwgdGhp
cyk7CiAKLSAgICBnX3NpZ25hbF9jb25uZWN0KG1fd2ViVmlldywgImRyYWctZGF0YS1yZWNlaXZl
ZCIsIEdfQ0FMTEJBQ0soK1tdKEd0a1dpZGdldCosIEdka0RyYWdDb250ZXh0KiBjb250ZXh0LCBn
aW50IHgsIGdpbnQgeSwgR3RrU2VsZWN0aW9uRGF0YSogZGF0YSwgZ3VpbnQgaW5mbywgZ3VpbnQg
dGltZSwgZ3BvaW50ZXIgdXNlckRhdGEpIHsKKyAgICBnX3NpZ25hbF9jb25uZWN0X2FmdGVyKG1f
d2ViVmlldywgImRyYWctZGF0YS1yZWNlaXZlZCIsIEdfQ0FMTEJBQ0soK1tdKEd0a1dpZGdldCos
IEdka0RyYWdDb250ZXh0KiBjb250ZXh0LCBnaW50IHgsIGdpbnQgeSwgR3RrU2VsZWN0aW9uRGF0
YSogZGF0YSwgZ3VpbnQgaW5mbywgZ3VpbnQgdGltZSwgZ3BvaW50ZXIgdXNlckRhdGEpIHsKICAg
ICAgICAgYXV0byYgZHJvcCA9ICpzdGF0aWNfY2FzdDxEcm9wVGFyZ2V0Kj4odXNlckRhdGEpOwog
ICAgICAgICBpZiAoZHJvcC5tX2Ryb3AgIT0gY29udGV4dCkKICAgICAgICAgICAgIHJldHVybjsK
QEAgLTIzMCwxMSArMjMwLDggQEAgdm9pZCBEcm9wVGFyZ2V0OjpkaWRQZXJmb3JtQWN0aW9uKCkK
ICAgICBhdXRvKiBwYWdlID0gd2Via2l0V2ViVmlld0Jhc2VHZXRQYWdlKFdFQktJVF9XRUJfVklF
V19CQVNFKG1fd2ViVmlldykpOwogICAgIEFTU0VSVChwYWdlKTsKIAotICAgIGF1dG8gb3BlcmF0
aW9uID0gcGFnZS0+Y3VycmVudERyYWdPcGVyYXRpb24oKTsKLSAgICBpZiAob3BlcmF0aW9uID09
IG1fb3BlcmF0aW9uKQotICAgICAgICByZXR1cm47CisgICAgbV9vcGVyYXRpb24gPSBwYWdlLT5j
dXJyZW50RHJhZ09wZXJhdGlvbigpOwogCi0gICAgbV9vcGVyYXRpb24gPSBvcGVyYXRpb247CiAg
ICAgZ2RrX2RyYWdfc3RhdHVzKG1fZHJvcC5nZXQoKSwgZHJhZ09wZXJhdGlvblRvU2luZ2xlR2Rr
RHJhZ0FjdGlvbihtX29wZXJhdGlvbiksIEdES19DVVJSRU5UX1RJTUUpOwogfQogCg==
</data>

          </attachment>
      

    </bug>

</bugzilla>