RESOLVED FIXED 70485
[GTK] fast/events/drag-selects-image.html fails 
https://bugs.webkit.org/show_bug.cgi?id=70485
Summary [GTK] fast/events/drag-selects-image.html fails
Philippe Normand
Reported 2011-10-20 02:30:17 PDT
Test added in http://trac.webkit.org/changeset/97878 fails consistently: --- /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/fast/events/drag-selects-image-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-debug/build/layout-test-results/fast/events/drag-selects-image-actual.txt @@ -11,6 +11,4 @@ Dragging image in non-editable area... 0 range(s) selected Dragging image in editable area... -1 range(s) selected -imageTwo is selected I'll skip it for now.
Attachments
Proposed patch (1.87 KB, patch)
2011-11-17 02:55 PST, Arko Saha 		eric: review-
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Arko Saha
Comment 1 2011-11-17 02:55:41 PST
Created attachment 115550 [details] Proposed patch
Philippe Normand
Comment 2 2011-11-17 08:39:29 PST
So the test is wrong? Can you confirm, Daniel?
Daniel Cheng
Comment 3 2011-11-17 10:48:27 PST
Do you know why your change fixes the issue for GTK? The result should be the same, as long as we're exceeding the image drag hysteresis.
Arko Saha
Comment 4 2011-11-18 04:28:08 PST
I tried to reproduce the issue in GtkLauncher. Following are the steps: 1. Drag the image with id: "imageTwo" out of the browser window, and drag it back into the GtkLauncher. 2. Drop the image into GtkLauncher. 3. The image is loaded in the browser window as main url. Same is observed while debugging DRT. Also in the test case if we comment out the line below : dragNowhere(document.getElementById('imageOne')); then the test case executes properly. I think this is an issue with DRT or Gtk platform and not in the Webcore drag drop module. Please let me know your thoughts on this.
Daniel Cheng
Comment 5 2011-11-18 09:16:09 PST
Hm. It's strange that commenting out the first test case helps it work. If unintended navigation is causing the GTK DRT to fail, one thing you could try is setting an ondrop handler for the page and preventing the default.
Ryosuke Niwa
Comment 6 2011-11-28 17:11:48 PST
Comment on attachment 115550 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=115550&action=review > LayoutTests/ChangeLog:8 > + Fixed typo error. This isn't really a typo, right? Please explain what's wrong with the existing code and how you fixed it.
Eric Seidel (no email)
Comment 7 2012-04-19 15:11:02 PDT
Comment on attachment 115550 [details] Proposed patch Yes, this needs more explanation. Otherwise the change looks reasonable. Do other platforms not fail this?
Martin Robinson
Comment 8 2015-05-07 18:18:04 PDT
Seems to be passing now.
Note You need to log in before you can comment on or make changes to this bug.