[Bug 43368] HashMyFiles: Drag & Drop from native File Managers (Dolphin, Nautilus, ...) does not work

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=43368

Damjan Jovanovic <damjan.jov at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |damjan.jov at gmail.com
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Damjan Jovanovic <damjan.jov at 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

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.