29264 2009-09-14 17:43:12 -0700 |pdwEffect| passed to WebView::Drop is incorrect. 2012-11-10 19:22:48 -0800 1 1 1 Unclassified WebKit New Bugs 528+ (Nightly build) PC Windows XP NEW P2 Normal --- 1 dbates webkit-unassigned aroben eric oliver oldest_to_newest 147231 0 dbates 2009-09-14 17:43:12 -0700 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. 150453 1 dbates 2009-09-27 20:49:13 -0700 This is a bug in WebKit. 150493 2 aroben 2009-09-28 06:06:03 -0700 How can we fix this? WebKit isn't calling WebView::Drop itself. Isn't this a bug in the caller of WebView::Drop? 151634 3 dbates 2009-10-01 11:28:38 -0700 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? 763635 4 173446 danya.postfactum 2012-11-10 05:23:17 -0800 Created attachment 173446 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. 763771 5 ap 2012-11-10 19:22:48 -0800 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. 173446 2012-11-10 05:23:17 -0800 2012-11-10 05:23:17 -0800 Demonstrates wrong dropEffect on drop dnd-test.html text/html 850 danya.postfactum PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCiAgICA8aGVhZD4NCiAgICAgICAgPHRpdGxlPjwvdGl0 bGU+DQogICAgPC9oZWFkPg0KICAgIDxib2R5Pg0KICAgIAk8YSBocmVmPSIjIiBpZD0iZHJhZ2dh YmxlIj5EcmFnZ2FibGU8L2E+DQogICAgCTxzY3JpcHQ+DQogICAgCQl2YXIgZHJhZ2dhYmxlID0g ZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ2RyYWdnYWJsZScpOw0KICAgIAkJdmFyIGRyb3B6b25l ID0gZG9jdW1lbnQ7DQogICAgCQlkcmFnZ2FibGUuYWRkRXZlbnRMaXN0ZW5lcignZHJhZ3N0YXJ0 JywgZnVuY3Rpb24oZSl7DQogICAgICAgICAgICAgICAgZS5kYXRhVHJhbnNmZXIuZWZmZWN0QWxs b3dlZCA9ICdsaW5rTW92ZSc7DQogICAgCQl9KTsNCiAgICAJCWRyb3B6b25lLmFkZEV2ZW50TGlz dGVuZXIoJ2RyYWdvdmVyJywgZnVuY3Rpb24oZSl7DQogICAgCQkJZS5wcmV2ZW50RGVmYXVsdCgp Ow0KICAgIAkJCWUuZGF0YVRyYW5zZmVyLmRyb3BFZmZlY3QgPSAnbW92ZSc7DQogICAgCQl9KTsN CiAgICAJCWRyb3B6b25lLmFkZEV2ZW50TGlzdGVuZXIoJ2RyYWdlbnRlcicsIGZ1bmN0aW9uKGUp ew0KICAgIAkJCWUucHJldmVudERlZmF1bHQoKTsNCiAgICAgICAgICAgICAgICBlLmRhdGFUcmFu c2Zlci5kcm9wRWZmZWN0ID0gJ21vdmUnOw0KICAgIAkJfSk7DQogICAgCQlkcm9wem9uZS5hZGRF dmVudExpc3RlbmVyKCdkcm9wJywgZnVuY3Rpb24oZSl7DQogICAgCQkJY29uc29sZS5sb2coZS50 eXBlLCBlLmRhdGFUcmFuc2Zlci5kcm9wRWZmZWN0KTsNCiAgICAJCQllLnByZXZlbnREZWZhdWx0 KCk7DQogICAgCQl9KTsNCiAgICAJPC9zY3JpcHQ+DQogICAgPC9ib2R5Pg0KPC9odG1sPg==