Downloader deletes and retries successful downloads if .crdownload file is being previewed
Reported by
agvulp...@gmail.com,
Nov 22 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Example URL: https://archive.org/download/toorcon-2013-ossmann-spread-spectrum/toorcon-2013-ossmann-spread-spectrum.mp4 Steps to reproduce the problem: 1. Right click and Save link as... to your drive. 2. While download in progress, preview file in VLC 3. When download finishes, file is deleted and download initiated again from scratch. What is the expected behavior? If Firefox cannot rename a download-in-progress .part file when the download completes, it just tries again when file renaming is unlocked. This is behavior is primarily so that Firefox can co-exist with antivirus/malware scanners that may take control of the file until it's deemed safe. It also allows you to preview media files without disruption to the download or user experience. Chrome should allow a user to "Open" or "Preview" a file that is in the process of downloading. Chrome should not destroy the file when it completes download, simply because it cannot immediately rename the file when it's being previewed (manually or otherwise), or being virus scanned, or is otherwise temporarily locked. What went wrong? Google Chrome's downloader won't let you select Open or Preview on a download that's in progress, even when most types of modern web media allow for incremental stream decoding. Manually opening a '.mp4.crdownload' file in VLC will play fine as Chrome 'buffers' the download-in-progress, but as soon as the download completes then Chrome immediately !DELETES! the file and attempts to download it again from scratch. Did this work before? N/A Chrome version: 62.0.3202.94 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: This behavior is the same whether using Chrome's default downloader or when using an extension like Download Manager 6.7.2
,
Nov 23 2017
,
Nov 28 2017
Able to reproduce this issue on Win 7,Ubuntu 14.04,Mac OS 10.12.6 using chrome reported version #62.0.3202.94 and canary #64.0.3279.0. Observed that: 1.Chrome is not allowing a user to "Open" or "Preview" a file that is in the process of downloading. 2.And also when downloading in progress,opened file for preview and noticed that after download finishes, file is deleted and download initiated again from scratch. These issue is seen from M-50 builds.Hence,marking it as Untriaged for further update from dev team. Thanks..
,
Nov 30 2017
I agree we should not delete the file if we fail to rename, but probably wait and retry depending on the cause of the failure. Playing streaming media formats will fail in the case of parallel downloads anyway, so I'm less concerned about that case than about the antivirus scenario.
,
Dec 5 2017
On point of "parallel downloads anyway", one shouldn't dismiss the feasibility of immediate media playback or preview while in the process of downloading. Many modern internet connections can download 5 minutes of video in the time it takes to watch 1 minute of video, which is more than adequate to allow a user an immediate viewing experience without having to first wait for download completion -- parallel segmented or otherwise. Preview also enables the user to abort a download they don't necessarily want anyway. I appreciate this comment is sounding more like a feature creep suggestion than a related to the bug report. It just happens that users are already previewing .crdownload files in absence of a direct UI integrated means, because it's already feasible, reasonable and works. |
||||
►
Sign in to add a comment |
||||
Comment 1 by manoranj...@chromium.org
, Nov 23 2017