Download fails when resuming a dangerous download |
|||
Issue descriptionSTEPS TO REPRODUCE: 1. Download any files 2. While downloading is in progress > Pull down the notification panel > Enable and disable Airplane mode 3. Wait for the file being downloaded to resume and observe OBSERVED RESULTS: The apk file being downloaded disappears from notifications after resuming. The file is not found in downloads app either. EXPECTED RESULTS: Download file should resume without any problem and finish downloading after we enable and disable Airplane mode.
,
Jan 20 2017
When resuming a dangerous download after browser crash, we will call DownloadTargetDeterminer to re-determine the download target. However, DownloadTargetDeterminer will recheck the download url and the referer during resumption, as the safe browsing list might have changed after download starts. Checking download url and the referer can potentially change the danger_type back to something unsafe. That causes the download controller to show the dangerous download infobar when download item updates its observers. However, since the download item is loaded from history service, there is no valid webcontent for it to show the infobar. This causes the download resumption to silently fail.
,
Jan 20 2017
qinmin: Can you confirm that this is happening for pretty much all .apk downloads? If so, that's important to track down.
,
Jan 20 2017
Yes, i can reproduce the issue with following steps: 1. download any apk. 2. while downloading, turn wifi off 3. kill Chrome 4. turn wifi on 5. restart chrome and wait for download to resume 6. download will fail silently
,
Jan 20 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d5d9f828c9c9366fa219e6a7aad6eccfdd2dd1fd commit d5d9f828c9c9366fa219e6a7aad6eccfdd2dd1fd Author: qinmin <qinmin@chromium.org> Date: Fri Jan 20 01:55:02 2017 Fix a problem that user validated dangerous download cannot resume After a dangerous download become user validated, it should be treated as not dangerous. However, Chrome currently still checks for downloadUrl and referer. This CL fixes the problem and added a test for the case. BUG= 682468 Review-Url: https://codereview.chromium.org/2641063002 Cr-Commit-Position: refs/heads/master@{#444941} [modify] https://crrev.com/d5d9f828c9c9366fa219e6a7aad6eccfdd2dd1fd/chrome/browser/download/download_target_determiner.cc [modify] https://crrev.com/d5d9f828c9c9366fa219e6a7aad6eccfdd2dd1fd/chrome/browser/download/download_target_determiner_unittest.cc
,
Jan 24 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by qin...@chromium.org
, Jan 18 2017