Work towards <rdar://problem/61368402>
Created attachment 400772 [details] Patch
Created attachment 400773 [details] Fix WinCairo build
Comment on attachment 400773 [details] Fix WinCairo build View in context: https://bugs.webkit.org/attachment.cgi?id=400773&action=review > Source/WebCore/ChangeLog:11 > + dispatching the "dragstart" event. There should be no change in behavior yet, since StaticPasteboard doesn't > + implement methods for writing data to the pasteboard, which this new method uses. This feels oddly backwards (landing the patch that does nothing because it calls unimplemented methods). But I assume the follow-up is coming shortly? > Source/WebCore/page/DragController.cpp:965 > + auto hitTestResult = hitTestResultForDragStart(src, *state.source, dragOrigin); Are we hit testing twice now? Must we?
Comment on attachment 400773 [details] Fix WinCairo build View in context: https://bugs.webkit.org/attachment.cgi?id=400773&action=review >> Source/WebCore/ChangeLog:11 >> + implement methods for writing data to the pasteboard, which this new method uses. > > This feels oddly backwards (landing the patch that does nothing because it calls unimplemented methods). But I assume the follow-up is coming shortly? The second part is on the way! >> Source/WebCore/page/DragController.cpp:965 >> + auto hitTestResult = hitTestResultForDragStart(src, *state.source, dragOrigin); > > Are we hit testing twice now? Must we? Hm…we might be able to, but then again it’s possible that the “dragstart” event handler might’ve changed the DOM such that the hit-tested node is no longer the same as it was during this point in time. I considered making prepareForDragStart() return an Optional<HitTestResult>, which could then be handed back to startDrag() to avoid the (probably) redundant hit-testing.
Committed r262469: <https://trac.webkit.org/changeset/262469> All reviewed patches have been landed. Closing bug and clearing flags on attachment 400773 [details].