NEW 77015
[GTK] fast/events/clear-drag-state.html and fast/events/clear-edit-drag-state.html fail 
https://bugs.webkit.org/show_bug.cgi?id=77015
Summary [GTK] fast/events/clear-drag-state.html and fast/events/clear-edit-drag-state...
Philippe Normand
Reported 2012-01-25 08:47:25 PST
The two tests added in r105659 are failing in GTK: --- /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/fast/events/clear-drag-state-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/fast/events/clear-drag-state-actual.txt @@ -1,4 +1,19 @@ This test ensures we clear the drag state at the end of each drag. To test manually, drag the green box below twice. You should observe the same list of events in the same order twice. Drag me down twice! -PASS +FAIL: +First drag: +span:span:dragenter +span:div:dragenter +div:div:dragenter +span:span:dragleave +span:div:dragleave + +Second drag: +div:div:dragleave +span:span:dragenter +span:div:dragenter +div:div:dragenter +span:span:dragleave +span:div:dragleave + --- /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/fast/events/clear-edit-drag-state-expected.txt +++ /home/slave/webkitgtk/gtk-linux-64-release/build/layout-test-results/fast/events/clear-edit-drag-state-actual.txt @@ -1,4 +1,19 @@ This test ensures we clear the drag state at the end of each drag. To test manually, drag the green box below twice. You should observe the same list of events in the same order twice. Drag me down twice! -PASS +FAIL: +First drag: +span:span:dragenter +span:div:dragenter +div:div:dragenter +span:span:dragleave +span:div:dragleave + +Second drag: +div:div:dragleave +span:span:dragenter +span:div:dragenter +div:div:dragenter +span:span:dragleave +span:div:dragleave +
Attachments
Add attachment proposed patch, testcase, etc.
Zan Dobersek
Comment 1 2012-07-13 05:00:04 PDT
I took some time to inspect these failures. Both tests pass (logs of the first and second drag are the same) when run manually, with the 'div:div:dragleave' line not appearing in the logs. It seems currently the webkit_web_view_drag_leave method must be called for the drag to be ended via drag controller. In these two test cases, the drag actually fails rather than leaves the web view, i.e. drag-failed signal is fired on the web view. This signal is currently handled in EventSender to stop the failed drag animation. The drag_leave method does get called eventually, but this happens when the second drag is already in progress. I've already made some successful attempts at fixing this test by tweaking the EventSender behavior, but ultimately every attempt ended up causing more regressions (but some new passes as well). Also CC-ing Martin.
Zan Dobersek
Comment 2 2012-07-13 05:01:23 PDT
(In reply to comment #1) > > Also CC-ing Martin. ... now.
Martin Robinson
Comment 3 2012-07-28 04:24:14 PDT
(In reply to comment #1) > Also CC-ing Martin. Perhaps WebKitGTK+ could just return FALSE from the drag-failed handler if in DRT mode?
Note You need to log in before you can comment on or make changes to this bug.