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.
Oh and TargetTypeNetscapeURL.
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?
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.
(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?
I can write a testcase, give me a couple of days.
Created attachment 202169 [details] Testcase
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
(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.
Created attachment 202223 [details] Patch
Comment on attachment 202223 [details] Patch Clearing flags on attachment: 202223 Committed r150350: <http://trac.webkit.org/changeset/150350>
All reviewed patches have been landed. Closing bug.