You need to
before you can comment on or make changes to this bug.
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.
This is a bug in WebKit.
How can we fix this? WebKit isn't calling WebView::Drop itself. Isn't this a bug in the caller of WebView::Drop?
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?
Created an attachment (id=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.
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.