[Webkit-unassigned] [Bug 191228] Plain text drag in contenteditable is always DragOperationCopy, never DragOperationMove

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=191228

--- Comment #10 from Jonathan Hammer <jonathan at e3software.com> ---
I took a look into adding a regression test similar to other tests found at LayoutTests/fast/events/drag-and-drop-*.html. Here is what I found in process of writing the test:

1. The test I wrote used eventSender to fake a drag via a series of mouse down/leap-forward/move-to/up calls. The test did not pass under WK2 (because <https://bugs.webkit.org/show_bug.cgi?id=68552>) but that's OK, because this bug only affects WK1 and thus only needs to pass under WK1.

2. When running the test on WK1 *before* applying my proposed patch, I was surprised to find that the bug did not reproduce and the test passed. This was confusing because the bug reproduces when the drag is performed manually (see attached Xcode project from earlier).

3. I took a deep dive into DumpRenderTree to figure out why. It turns out that EventSender queues up the fake mouse events and only replays them once mouseUp() is called. The events are replayed synchronously (i.e. the run loop is not spun after each event -- see +[EventSendingController replaySavedEvents]).

4. The fact that the events are replayed synchronously means that the buggy codepath is not exercised and the bug never manifests. This is because, under DRT, the drag is over and finished by the time beginDrag calls cleanupAfterSystemDrag. However, in real world usage, the drag would still be in progress when beginDrag calls cleanupAfterSystemDrag (thus triggering the bug).

===

If my understanding is correctly, I think there could be two ways to resolve this:

1. Fix DRT so that +[EventSendingController replaySavedEvents] plays back one event each time through the run loop, instead of replaying them all at once

2. Instead of writing a LayoutTest, just write a ManualTest for this bug

My preference would be for #2. Messing with DRT seems too risky for a bug as small as this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181107/a6efe2ce/attachment-0001.html>