Copying file from download bar blocks UI in all tabs/windows until copy complete
Reported by
mattg...@gmail.com,
Feb 8 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Download a file in Chrome. 2. Drag-and-drop file from Download bar to a destination in Windows Explorer What is the expected behavior? Copy process should be non-blocking to UI. What went wrong? The UI is blocked in all tabs/windows until the file copy is complete. This is particularly noticable if you copy a large file and/or to a slow destination, e.g. a network share over WAN. Did this work before? No Chrome version: 56.0.2924.87 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 24.0 r0 Workaround is to do the file copy completely in Windows Explorer, i.e. open %userprofile%\Downloads in Windows Explorer and copy the file from there instead of using the Downloads bar in Chrome.
,
Feb 8 2017
To handle async drag'n'drop properly [1], IASyncOperation interface should be implemented (done, see [2]), but it should be used in a new thread that handles the transfer. Apparently, Chrome doesn't create it. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/bb776904(v=vs.85).aspx#async [2]: https://cs.chromium.org/chromium/src/ui/base/dragdrop/os_exchange_data_provider_win.cc
,
Feb 9 2017
Able to reproduce this issue on Win-10 using chrome reported version #56.0.2924.87 and latest canary #58.0.3006.0. Unable to reproduce this issue in Ubuntu and Mac. This is a non-regression issue as it is observed from M30 old builds. Hence, marking it as untriaged to get more inputs from dev team. Thanks...!!
,
Aug 9
,
Aug 9
,
Nov 22
*** UI Mass Triage*** Tested on latest Canary #72.0.3618.0 on Windows 10 and was able to reproduce the issue. Hence, adding appropriate labels. Thanks! |
||||
►
Sign in to add a comment |
||||
Comment 1 by ligim...@chromium.org
, Feb 8 2017