Bug 29264 - |pdwEffect| passed to WebView::Drop is incorrect.
: |pdwEffect| passed to WebView::Drop is incorrect.
Status: NEW
Product: WebKit
Classification: Unclassified
Component: New Bugs
: 528+ (Nightly build)
: PC Windows XP
: P2 Normal
Assigned To: Nobody
Depends on:
  Show dependency treegraph
Reported: 2009-09-14 17:43 PDT by Daniel Bates
Modified: 2012-11-10 19:22 PST (History)
3 users (show)

See Also:

Demonstrates wrong dropEffect on drop (850 bytes, text/html)
2012-11-10 05:23 PST, danya.postfactum
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Bates 2009-09-14 17:43:12 PDT
The value of the drop effect (|pdwEffect|) passed to WebView::Drop is incorrect. That is, it does not reflect the drop effect as seen by the last WebView::DragOver call.

A temporary workaround is to store the last drop effect in WebView::m_lastDropEffect. We set this variable in WebView::DragEnter and WebView::DragOver so that it can be used in WebView::Drop to set the correct drop effect. Thus, on return from DoDragDrop (http://msdn.microsoft.com/en-us/library/ms678486%28VS.85%29.aspx) we have the correct |pdwEffect| for the drag-and-drop operation.
Comment 1 Daniel Bates 2009-09-27 20:49:13 PDT
This is a bug in WebKit.
Comment 2 Adam Roben (:aroben) 2009-09-28 06:06:03 PDT
How can we fix this? WebKit isn't calling WebView::Drop itself. Isn't this a bug in the caller of WebView::Drop?
Comment 3 Daniel Bates 2009-10-01 11:28:38 PDT
Oops, I misspoke. It "may" be a Microsoft bug.

I say may because it is not explicitly clear from the DoDragDrop API <http://msdn.microsoft.com/en-us/library/ms678486%28VS.85%29.aspx> what the value of pdwEffect will be when Drop is called.

The API states that:
"If the return value is DRAGDROP_S_DROP, DoDragDrop calls IDropTarget::Drop. The DoDragDrop function returns the last effect code to the source, so the source application can perform the appropriate operation on the source data, for example, cut the data if the operation was a move."

But does not elaborate what "last effect code" means. On first read, I took it to mean the last effect code as set by some function (either DragEnter, DragOver, or Drop) during the course of the drag-and-drop operation. That is, suppose only one of the aforementioned functions sets the drop effect code, say DragEnter, and that the drop effect is set to DROPEFFECT_COPY. Then, the pdwEffect passed to DragOver, and Drop will be DROPEFFECT_COPY and unless these functions explicitly change it, DROPEFFECT_COPY would be the last effect code.

This is not the case. From working in the debugger, it appears that the "last effect code" means the value of the parameter dwOKEffects (as passed to DoDragDrop) unless changed in the Drop function (by setting pdwEffect to something else). (i.e. by default, Drop is passed pdwEffect = dwOKEffects).

(In reply to comment #2)
> How can we fix this? WebKit isn't calling WebView::Drop itself. Isn't this a
> bug in the caller of WebView::Drop?
Comment 4 danya.postfactum 2012-11-10 05:23:17 PST
Created attachment 173446 [details]
Demonstrates wrong dropEffect on drop

Holy shit! Almost 2013 year, and this bug still is present.

Open attachment in Chrome or Safari. Open Console. Grag the link and drop it on document. You get "drop none" instead of "drop move" (the script set dropEffect to "move" on dragenter/dragover.

I have reproduced this bug on all platforms - Linux, Windows 7, Mac OS.
Comment 5 Alexey Proskuryakov 2012-11-10 19:22:48 PST
Please file a new bug about what you are seeing on Mac. This bug is very specifically about Windows, and it will not be used to track the issue you are seeing.