https://bugs.winehq.org/show_bug.cgi?id=43368
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #2 from Damjan Jovanovic damjan.jov@gmail.com --- Confirming. Still happens in Wine 5.0-rc2.
With WINEDEBUG='+xdnd':
0009:trace:xdnd:XDNDDATAOBJECT_GetData (0x63f46958, 0x31b4f8, 0x31b50c) 0009:trace:xdnd:XDNDDATAOBJECT_GetData application is looking for CF_HDROP 0009:trace:xdnd:XDNDDATAOBJECT_QueryGetData (0x63f46958, 0x31b4f8={.tymed=0x1, .dwAspect=0, .cfFormat=15} 0009:fixme:xdnd:XDNDDATAOBJECT_QueryGetData only the content aspect is supported right now
.dwAspect=0 is invalid, the valid values start from 1: include/wtypes.idl: DVASPECT_CONTENT = 1, include/wtypes.idl: DVASPECT_THUMBNAIL = 2, include/wtypes.idl: DVASPECT_ICON = 4, include/wtypes.idl: DVASPECT_DOCPRINT = 8
It is surprising that Windows allows this. I wonder how it's implemented. Is 0 always taken to mean DVASPECT_CONTENT? Does it depend on the clipboard format, eg. does only CF_HDROP ignore .dwAspect, or do others?
The drop still succeeds despite GetData() failing, but with no file, which is potentially dangerous, as if the operation was "Move" instead of "Copy", the file manager could delete the file:
0009:trace:xdnd:X11DRV_XDND_DropEvent drop succeeded 0009:trace:xdnd:X11DRV_XDND_DropEvent effectRequested(0x1) accept(1) performed(0x1) at x(815),y(417) 0009:trace:xdnd:X11DRV_XDND_FreeDragDropOp