New issue
Advanced search Search tips

Issue 832023 link

Starred by 3 users
Status: Assigned
Owner:
qin...@chromium.org
Cc:
nyerramilli@chromium.org
rbasuvula@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression : Download entry does not get deleted even after removing the file from OS folder.

Reported by avsha...@etouch.net, Apr 12 2018 
Chrome Version : 66.0.3359.106 (Official Build) 580e8ed9017368bf40061fa0b9618ad381082b0a-refs/branch-heads/3359@{#693} 32/64-bit
OS : Windows(7,8,8.1,10), Mac(10.12.6, 10.13.1, 10.13.5), Linux(14.04 LTS) 

What steps will reproduce the problem?
1. Launch chrome, navigate to chrome://downloads page, hit CTRL + S and save the current page.
2. Click on 'Show in folder' and delete the Downloaded file from OS.
3. Head back to chrome://downloads and kill the page using chrome://kill command.
4. Reload the page and observe the downloaded entry on chrome://downloads page.

Actual Result : Download entry does not get deleted even after removing the file from OS folder.

Expected Result : Download entry should get sticked out after removing the source file from OS folder.

This is a regression issue, broken in M-65 and providing the bisect using per-revision script:
Good Build : 65.0.3286.0 (Revision : 521957)
Bad Build : 65.0.3287.0 (Revision : 522296)

You are probably looking for a change made after 522206 (known good), but no later than 522207 (first known bad).

CHANGE-LOG URL:
https://chromium.googlesource.com/chromium/src/+log/f0c5b69e33aaf67089ff8dc584bac670b0168c62..8e333b2c009f030f93165d00c7a858d6bb1518a2

Suspect : https://chromium.googlesource.com/chromium/src/+/8e333b2c009f030f93165d00c7a858d6bb1518a2

@ Min Qin : Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note : 
1. Issue is also observed on Canary #67.0.3395.0, Dev #67.0.3393.4 and Stable #65.0.3325.181 builds.
Actual_Downloads.mp4
511 KB View Download
Expected_Downloads.mp4
417 KB View Download

Comment 1 by asanka@chromium.org, Apr 13 2018 

If you don't do steps 3 and 4, the result is the same, correct?

The downloads page doesn't monitor the file system, and isn't expected to react to file system changes in real time. This part is expected. Killing and restarting the renderer process is not something users typically do, nor is it a method we advise people to use if they want to refresh the file existence state.

Not objecting to fixing this if the downloads folks think it's useful, but I don't think the additional complexity of responding to renderer restarts by redoing the file existence check gets users any practical benefit.

I'd understand if we are wiring up F5 to re-do the file existence check. But AIUI that's not what happening here.
►

Sign in to add a comment