|CF_HDROP implementation prevents drops to most Windows applications|
|Reported by mprik...@gmail.com, Oct 7 2015||Back to list|
UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36 Steps to reproduce the problem: 1. Drag a file from Chrome to any 3rd party Windows application that implements custom handling of dropped files (WinZip, WinRAR, 7-zip, WinSCP, FileZilla). 2. The target application is seemingly willing to accept the file (presented by the mouse cursor), but when you actually release the mouse button, nothing happens (in case of WinSCP 5.7.5, it even crashes) What is the expected behavior? - Either the file should be dropped on the target application (preferred) - Or the application should not accept the drop What went wrong? The reason behind this is that while the IDataObject.QueryGetData (of the drag object from Chrome) succeeds for CF_HDROP (hence the target application believes it can accept the drop), the IDataObject.GetData fails. FORMATETC FormatEtc; FormatEtc.cfFormat = CF_HDROP; FormatEtc.ptd = NULL; FormatEtc.dwAspect = DVASPECT_CONTENT; FormatEtc.lindex = -1; FormatEtc.tymed = TYMED_HGLOBAL; // Returns S_OK HRESULT QueryGetDataResult = DataObj->QueryGetData(&FormatEtc); STGMEDIUM StgMedium; // Returns DV_E_FORMATETC HRESULT GetDataResult = DataObj->GetData(&FormatEtc, &StgMedium); Did this work before? N/A Chrome version: 45.0.2454.101 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 19.0 r0
Oct 6 2016,
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Oct 6 2016,
This still repros in 55.0.2881.5; drops to Windows Explorer still work correctly but other application targets fail. Simpler repro: https://whytls.com/test/drag/ When the dragged file is dragged over another application, the function PrepareDragForDownload in web_contents_view_aura.cc runs and creates a temporary folder named "chrome_drag#PID#_#RANDOM#" under AppData\Local\Temp. When the drop is completed on Explorer, the file is downloaded to the temp path, tagged with a mark-of-the-web, and Explorer attempts to copy it to the destination. The temporary file and folder are scheduled for deletion at next reboot. In contrast, when the drop is completed on another file-accepting application, the file is not downloaded to that temp path and the drop fails. In the case of 7zfm, the drop fails because when GetData(HDROP) is called, this test fails: // Fail all GetData() attempts for DownloadURL data if the drag and drop // operation is still in progress. if (in_drag_loop_) return DV_E_FORMATETC; ... and there are no subsequent queries for data. In the case of drops to Wordpad and Notepad, the request for GetData(HDROP) exits here: if (!in_async_mode_ || async_operation_started_) wait_for_data = true; if (!wait_for_data) return DV_E_FORMATETC; In the case of Explorer, the first six calls to GetData(CF_HDROP) fail; the first three because in_drag_loop_ and the last three because !wait_for_data. Then the checks pass, the function recurses into itself and DuplicateMedium is called and S_OK is returned.
Oct 6 2016,
The fundamental issue here is that Chrome is trying to perform a "Delay Rendering" operation for a basic CF_HDROP type. If the client indicates to Chrome that it is handling the drop acceptance operation on a background thread (via the IDataObjectAsyncCapability::StartOperation method on the data object) then Chrome will download the data and provide the filename via the CF_HDROP parameter). Very few Windows applications support the asynchronous capabilities for drag/drop (see e.g. https://msdn.microsoft.com/en-us/library/windows/desktop/bb776904(v=vs.85).aspx#async for background), especially those reliant upon the old-style filename drops via CF_HDROP. If the client does not indicate it is performing an async drop, Chrome refuses to fill the CF_HDROP parameter in the hopes of preventing the client application from hanging while a download operation occurs on what is presumed to be a UI thread. If you comment out "if (!wait_for_data) return DV_E_FORMATETC;" in the Chrome's source, applications like Notepad and Wordpad can accept such drops from Chrome. 7zfm will not accept drops, likely because it's trying to grovel the CF_HDROP filenames on drag enter instead of waiting for a drop: CDropTarget::DragEnter(...) GetNamesFromDataObject(dataObject, m_SourcePaths); QueryGetData(dataObject); ...
Oct 7 2016,
Nov 1 2016,
Was able to repro on Windows 10 and Outlook 2016.
Nov 1 2016,
Issue 160544 has been merged into this issue.
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
|► Sign in to add a comment|