Able to reproduce issue on Windows 7 and 10 with latest Chrome stable i.e., 57.0.2987.133, Please find the bisect result below :

Bisect result :
You are probably looking for a change made after 434737 (known good), but no lat
er than 434738 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/c43462be8948e6a3a1c9a7d6bc6b10fc5fc789b8..64558cd6c0e060c1f127f8f36f692529c8087aae


Note : The CL which I got as suspect was intended for Android based but the files which were touched were desktop related, Please correct me if I am wrong.

I will check this on Chrome beta and dev and update soon.

Able to reproduce with Chrome Beta(58.0.3029.68), Unable to reproduce the same on Dev channel(59.0.3067.6)


Note : The same works fine on Mac.

Chrome has a commit schedule of 10 seconds, so each database change is not committed immediately. They are gathered together until commit happens.

My CL marks some of the db change as important so that it will trigger a commit immediately.

Now during test, how long does it took between step 3 and 4. Removing a download item is not high priority, so you need to wait 10 seconds to ensure the db commit happens.  I am not sure whether desktop can perform a clean shutdown when user closes Chrome (commit all pending db changes when closing chrome). If it does, then the 10 seconds wait is not needed. 

I have re-bisected again with more then 10sec of wait time and I still see the issue and my bisect result is similar to what I have posted in Comment#1.

Please find the Manual bisect which I have performed and to make sure the suspected CL is in the range of Manual bisect as well : 

Last Good Build : 57.0.2935.0 
First bad Build : 57.0.2936.0

Change Log :https://chromium.googlesource.com/chromium/src/+log/57.0.2935.0..57.0.2936.0?pretty=fuller&n=10000

I am tagging OS Android and Chrome OS for respective team to check if they can reproduce the issue.

candrada@, I can't repro this, though I only tried a single file and not many scenarios - can you please have someone test this and then remove OS-Android if we can't reproduce?

RB-Beta > RB-Stable so we'll just use that tag.

kravula@, can you repro?  Thanks.

could https://codereview.chromium.org/2528193002 cause this issue?

Tried on M58(58.0.3029.54)/Samsung S5(SM-G900V VERIZON) and cannot repro this issue.

Steps followed:

1. Launch the app
2. Open new tab and enter the test url that has multiple files to install "http://tinyurl.com/owpgojg"
3. Start downloading multiple files and wait for complete files
4. Go to Download Home and delete all downloaded files
5. Close the chrome and re-launch again

Observed behavior: Download Home page is empty... deleted files are not present in this page.

Tried same scenario with downloading duplicate files and also observed same behavior(not restoring any deleted files)

Video link:
http://go/chrome-androidlogs1/7/711337

Given that the issue only happens on M57 and 58, and doesn't repro on M59, I don't think this should be a beta-blocker (if it is a blocker, it should be a stable blocker instead).

And the bug doesn't feels like it is critical, so I don't think it is stable blocker either.

If we cannot repro it on M59, I will just let the issue stay as it is as we are very close to the stable branch cut. I will try to repro this on the trunk to see if we need to further investigate this.

My gut feeling is that somehow the db commit isn't properly propagated to the persistent storage. No idea why this happens, possibly something wrong with the sqlite implementation

As per the bug, the issue already exist in M57, so removing the blocker label.Please feel to add if needed.