New issue
Advanced search Search tips
Starred by 6 users

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug

Blocked on:
issue 653952

Sign in to add a comment

CF_HDROP implementation prevents drops to most Windows applications

Reported by, Oct 7 2015

Issue description

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.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);

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
Project Member

Comment 1 by, Oct 6 2016

Status: Archived (was: Unconfirmed)
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 - Your friendly Sheriffbot
Components: -UI Blink>DataTransfer
This still repros in 55.0.2881.5; drops to Windows Explorer still work correctly but other application targets fail. 

Simpler repro:

When the dragged file is dragged over another application, the function PrepareDragForDownload in 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.
Components: UI>Browser>Downloads
Labels: -Pri-2 Pri-3
Status: Untriaged (was: Archived)
Summary: CF_HDROP implementation prevents drops to most Windows applications (was: When dropping files from Gmail, the CF_HDROP is implemented incorrectly)
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. 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:
    GetNamesFromDataObject(dataObject, m_SourcePaths);

Blockedon: 653952
Status: Available (was: Untriaged)
Was able to repro on Windows 10 and Outlook 2016.
 Issue 160544  has been merged into this issue.
Project Member

Comment 7 by, Nov 2 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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 - Your friendly Sheriffbot
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
Un-cc-ing me from all bugs on my final day.

Sign in to add a comment