Curious, why do we keep the file at all? Given limited space on chromebooks I'd like to automatically delete if a download is terminated. 

Hi, fukino, I have this issue on occasion even when downloading. Maybe you will take this over and fix them both.

https://bugs.chromium.org/p/chromium/issues/detail?id=620919&q=crdownload&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

*even when the download is successful*

Re:#2
It looks a separated bug and tracked in  Issue 580906 .
In this bug, we focus on the bug occurring on Chrome OS.

Re:#1
I guess the file was not deleted due to a bug...

My concern is that .crdownload files can be stored in Downloads in some cases (listed below), and they can take up space invisibly forever.
- Chrome fails to clean-up the .crdownload file due to a bug.
- User downloads a file which has .crdownload extension. (Unlikely, but the behavior can be abused.)
- User renames a file to *.crdownload.

So, I think showing *.crdownload is safer.
WDTY?

Weifang, Do you agree with the approach in #5?

Assigning to Weifang for response.

Thoughts -
(1) I think the key issue here is that we need to ensure we are successfully deleting the file if the user cancels the download. Is there still a bug surrounding this behavior?

(2) In the case where we do have an unexpected issue, I agree that we should show the *.crdownload file. The user should have the ability to manually remove this file if they choose.

I can confirm that I can't see .crdownload files (after canceling the download).

On  crbug.com/409490  an user says that they use the .crdownload file to start watching the video even before the end of the download. Smart user. :-)

So, re-enabling the display of .crdownload files seems correct to me.

So there's a flag in the gear menu that an inspired user can use to see dot files and crdownload files ("Show Hidden Files").

But it seems crdownload shouldn't be hidden anyways, so making this change.

Seems sane to me.  Use "Show Hidden Files" for users of type #10.  

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/587fff9cb8ce4be7ffc416d1a746f62f62ad11ac

commit 587fff9cb8ce4be7ffc416d1a746f62f62ad11ac
Author: Stuart Langley <slangley@google.com>
Date: Wed Dec 19 05:34:22 2018

Show files ending with .crdownload in the file manager again.

It appears this was not tested, so added a basic test to the gear_menu
test as well.

Bug:  616069 
Change-Id: Iec705221deb64f07cbb59da84682f6bd588b0a82
Reviewed-on: https://chromium-review.googlesource.com/c/1382660
Commit-Queue: Stuart Langley <slangley@chromium.org>
Reviewed-by: Noel Gordon <noel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617734}
[modify] https://crrev.com/587fff9cb8ce4be7ffc416d1a746f62f62ad11ac/ui/file_manager/file_manager/foreground/js/directory_contents.js
[modify] https://crrev.com/587fff9cb8ce4be7ffc416d1a746f62f62ad11ac/ui/file_manager/integration_tests/file_manager/gear_menu.js
[modify] https://crrev.com/587fff9cb8ce4be7ffc416d1a746f62f62ad11ac/ui/file_manager/integration_tests/test_util.js