Issue metadata
Sign in to add a comment
|
Drag-and-dropping images to a folder on my PC no longer uses the original filename
Reported by
showal...@arbormoon.com,
Mar 16 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3042.4 Safari/537.36 Example URL: https://image.shutterstock.com/z/stock-photo-group-of-multiethnic-diverse-busy-business-people-concept-337088285.jpg Steps to reproduce the problem: 1. Load any image from any site (non-linked image) 2. Drag and drop the image from the browser to a folder window (e.g. File Explorer window in Windows 7) 3. File name is now "download.jpg" instead of "whatever-the-image-filename-is-on-the-site.jpg" as it has always been. What is the expected behavior? I expect the auto-generated file name to match what is on the website/server where the image file was downloaded from. What went wrong? The behavior changed from what it was in the past (and if I recall, what the behavior of the current version of actual Chrome uses right now). I download tons and tons of images from stock photo sites using drag and drop because it speeds up my workflow immensely. Now that I have to change the filename manually, I can no longer use Chrome. PLEASE PLEASE PLEASE change this back to the previous behavior, of auto-naming the file with the source filename, not the generic "download.jpg" or "download.png". Did this work before? Yes Works properly in current version of Chrome (v56) at least on Mac, but I believe also Windows. I first started noticing the issue in Chrome Canary v59.0.3040.0 but it was working properly I believe within the past month before that in Chrome Canary. Chrome version: 59.0.3042.4 Channel: canary OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: I was living the dream, but now it's a total nightmare. Hoping to wake up real soon! ;{ I think many other people will also complain about this if the change was intentional, if it ever hits Chrome itself...
,
Mar 16 2017
Also worth noting that I can easily reproduce this, and seems like we want this fixed before M-59 goes stable.
,
Mar 16 2017
//net has some of the filename generation logic, but the issue isn't there.
,
Mar 16 2017
,
Mar 17 2017
Thanks for putting such quick attention on this. I'm not sure where the issue was affected, //Net or otherwise. I'm not too familiar with the innards of Chromium. That's why I look up to you all. Keep on rocking the world. :)
,
Mar 17 2017
Going to go ahead and label this a release blocker - seems like this would require explicit consideration before M-59 goes to stable with this bug (I assume it will be fixed by then, anyways, just being paranoid).
,
Apr 4 2017
Friendly ping to get an update on this issue marked as Blocker.
,
Apr 4 2017
xingliu@ can you take a look? Looks like a regression in the past few weeks.
,
Apr 4 2017
,
Apr 4 2017
Also reproduced on linux. If we drag a second file, file name would be something like download 2.png. This looks also weird since previously it will be renamed to download(1).png.
,
Apr 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0b5c13253a5c567373cf037d336a998601105082 commit 0b5c13253a5c567373cf037d336a998601105082 Author: xingliu <xingliu@chromium.org> Date: Wed Apr 05 02:23:18 2017 Fix an issue that drag and drop image always has default file name. The reason is content::DropData is passed between renderer and browser through IPC message, but we didn't declare several fields as IPC_STRUCT_TRAITS. Also noticed content::DropData.file_mime_types and did_originate_from_renderer are also not declared. This CL didn't add those in case it breaks something else. BUG= 702173 Review-Url: https://codereview.chromium.org/2803473003 Cr-Commit-Position: refs/heads/master@{#461942} [modify] https://crrev.com/0b5c13253a5c567373cf037d336a998601105082/content/common/drag_traits.h
,
Apr 5 2017
,
Apr 5 2017
Mark as fixed?
,
Apr 5 2017
Issue 705450 has been merged into this issue.
,
Apr 5 2017
,
Apr 10 2017
Issue 709791 has been merged into this issue.
,
Apr 10 2017
Can you add a test for that?
,
Apr 11 2017
Tested the issue on Windows-7 using Chrome version 59.0.3067.6 as per the comment #0 Observed that the fix is working as expected.Hence adding the verified labels. Please find the attached screen cast for reference. Thanks.
,
Apr 15 2017
This very annoying bug still exists/has resurfaced. Drag-and-dropped images get renamed download.jpg Running: Chrome 58.0.3029.68 beta (64-bit) Windows 7 64-bit
,
Apr 16 2017
This regressed on r488946, which went out with 58, not 59. We should try merge this fix back if it's still possible.
,
Apr 16 2017
Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions. Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 17 2017
I try to merge, but ran into an issue that I'm not in chromium-committers gerrit group, just file a bug to Infra-Git. Should I do something else for adding into gerrit group?
,
Apr 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1acc80de5dad9f57345eaa92b1da17212254e8cb commit 1acc80de5dad9f57345eaa92b1da17212254e8cb Author: Xing Liu <xingliu@chromium.org> Date: Mon Apr 17 18:05:38 2017 Fix an issue that drag and drop image always has default file name. The reason is content::DropData is passed between renderer and browser through IPC message, but we didn't declare several fields as IPC_STRUCT_TRAITS. Also noticed content::DropData.file_mime_types and did_originate_from_renderer are also not declared. This CL didn't add those in case it breaks something else. BUG= 702173 Review-Url: https://codereview.chromium.org/2803473003 Cr-Commit-Position: refs/heads/master@{#461942} (cherry picked from commit 0b5c13253a5c567373cf037d336a998601105082) Review-Url: https://codereview.chromium.org/2824803002 . Cr-Commit-Position: refs/branch-heads/3029@{#735} Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471} [modify] https://crrev.com/1acc80de5dad9f57345eaa92b1da17212254e8cb/content/common/drag_traits.h
,
Apr 17 2017
merged to M58.
,
Apr 19 2017
Verified the issue on Windows-7 using Chrome version 58.0.3029.81 as per the comment #0 Observed that the fix is working as expected.Hence adding the verified labels. Please find the attached screen cast for reference. Thanks.
,
Apr 30 2017
File name is now OK. But it still doesn't preserve the file extension. :-( |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by mmenke@chromium.org
, Mar 16 2017Components: UI>Browser>Downloads
Labels: -Pri-2 Pri-1