Bug 113962 – GtkSelectionData length is off by one

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Daniel Narvaez]

If you drag a link from webkit to another gtk widget, which supports text/uri-list, the GtkSelectionData passed to the drag-data-received event will have the wrong length. In fact it will include the NULL termination.

It looks like the issue might be here

https://trac.webkit.org/browser/trunk/Source/WebCore/platform/gtk/PasteboardHelper.cpp#L175

The + 1 there seems wrong to me. Similar issue with TargetTypeMarkup.

[Daniel Narvaez]

Oh and TargetTypeNetscapeURL.

[Martin Robinson]

Thanks for reporting this bug. Is it causing any visible issues? I've been looking at the drag-and-drop atom contents for different browsers and it seems they are all differ. For instance, I ran the paste program from: http://www.edwardrosten.com/code/x11.html like so:

./paste -dnd text/uri-list

After dragging a link 38 characters long, this is what I see in various browsers:

* Chromium: Number of items: 40
* Epiphany: Number of items: 39
* Firefox: Number of items: 38

If all browsers do something different and this isn't causing issues, I'm tempted keep things as they are. If not, what widgets are showing issues and are they reproducible with Chromium?

[Daniel Narvaez]

If you drag a link from a webkitgtk widget to an application which uses pygobject Gtk.SelectionData.get_data, you will get uris with an extra \x00 at the end. In C applications I think it's normally not user visible because the string is null terminated anyway.

[Martin Robinson]

(In reply to comment #3)
> If you drag a link from a webkitgtk widget to an application which uses pygobject Gtk.SelectionData.get_data, you will get uris with an extra \x00 at the end. In C applications I think it's normally not user visible because the string is null terminated anyway.

Do you have an example somewhere that illustrates this problem?

[Daniel Narvaez]

I can write a testcase, give me a couple of days.

[Daniel Narvaez]

Created attachment 202169 [details]
Testcase

[Daniel Narvaez]

If you run the testcase, drag a link from the web view to the empty window, the url with the final \x00 will printed out.

I got different results than yours testing this with firefox and epiphany with this testcase. I dragged the planet link on webkitgtk.org and firefox worked as expected, epiphany failed in the same way as webkit. That's more in line with what I'd have expected.

firefox 10.0.12
epiphany 3.4.2
webkit 1.8.1

[Martin Robinson]

(In reply to comment #7)
> If you run the testcase, drag a link from the web view to the empty window, the url with the final \x00 will printed out.
> 
> I got different results than yours testing this with firefox and epiphany with this testcase. I dragged the planet link on webkitgtk.org and firefox worked as expected, epiphany failed in the same way as webkit. That's more in line with what I'd have expected.
> 
> firefox 10.0.12
> epiphany 3.4.2
> webkit 1.8.1

Thanks very much for the test case. Chromium's data is two characters longer because it includes a carriage return and a newline. Firefox includes neither. I'll try to have a fix today.

[Martin Robinson]

Created attachment 202223 [details]
Patch

[Martin Robinson]

Comment on attachment 202223 [details]
Patch

Clearing flags on attachment: 202223

Committed r150350: <http://trac.webkit.org/changeset/150350>

[Martin Robinson]

All reviewed patches have been landed.  Closing bug.