Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 6 users
Status: Available
Owner: ----
Cc:
Components:
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 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
 
Project Member Comment 1 by sheriffbot@chromium.org, Oct 6 2016
Status: Archived
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
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: 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.
Components: UI>Browser>Downloads
Labels: -Pri-2 Pri-3
Status: Untriaged
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. 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);
    ...

Blockedon: 653952
Status: Available
Was able to repro on Windows 10 and Outlook 2016.
Cc: benjhayden@chromium.org scottmg@chromium.org asanka@chromium.org e...@chromium.org dcheng@chromium.org
 Issue 160544  has been merged into this issue.
Sign in to add a comment