Summary: | |pdwEffect| passed to WebView::Drop is incorrect. | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Daniel Bates <dbates> | ||||
Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | NEW --- | ||||||
Severity: | Normal | CC: | aroben, eric, oliver | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Attachments: |
|
Description
Daniel Bates
2009-09-14 17:43:12 PDT
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 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.
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. |