Tested the issue on the reported Chrome #65.0.3309.0 on SM- J710F Android 7.0.0 Build/NRD90M and Pixel 2 Android 8 and not able to reproduce the issue by following the below steps:

1. Launched the Chrome browser.
2. Navigated to the URL: m.demotywatory.pl/4821952
3. Long tap on the video, to get the Download option.
4. Download the video.
5. Observed that '.mp4' extension is displayed for the downloaded videos.

marcin@-- Could you please verify your device setting and let us know your observations.

Attached screenshots for reference.

Thanks in advance!

Deleted: 798225-1.png 56.4 KB

	798225-1.png 56.4 KB View Download

Deleted: 798225-2.png 51.7 KB

	798225-2.png 51.7 KB View Download

demotywatory.pl seems to serve videos in different way - I suspect, that sometimes without path info (OK for Chrome), sometimes with path (not OK for Chrome). In second case, when you try to download video again, you see "do you want to download file m.demotywatory.pl/uploads/id1/id2/filename.mp4 again?" instead of "do you want to download file filename.mp4 again?".

Just try many times on different videos, problem seems to be connected with function extracting filename.

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

marcin@ -- Tested on SM- J710F Android 7.0.0 and Nexus 5 Android 6.0.1, if the same file is downloaded again "Do you want to download video.mp4 again?" alert is displayed (without path).

Could you please provide the device model and version where such behavior is displayed. It would help us in reproducing and triaging the issue.

Thanks in advance!

Deleted: 798225-DownloadAgain.png 115 KB

	798225-DownloadAgain.png 115 KB View Download

I don't know if sample-videos.com behaves the same, but I still issue on demotywatory.pl. Try maybe download the same videos many times in parallel (by opening context menu few times and clicking "Download videos" few times). For me today happened after few attempts.

Android 7 / S7.

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

marcin@ -- Tested downloading 10 files and few in parallel on SM- J710F Android 7.0.0 and couldn't reproduce the issue. Could you please share screencast and logs when the issue gets reproduced.

Attached screenshot for reference.

Thanks!

I've confirmed with latest Chrome canary version, that it's enough to:

1. download video using "download video" from context menu
2. few times open context menu, click "download video" (it's enough to see "do you want to download file.mp4 again?") and click "x" closing popup
3. repeat step 2 few times

and you get file with correct name and files with .com.google.Chrome.SOMEID in the Downloads directory

please maybe find S7 to reproduce it, I don't believe it's device dependent, but maybe...

Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

when you click on a download link, chrome will starts saving the incoming data to a temporary file named .com.google.Chrome.SOMEID. 

If there is no file name conflicts, that file will be renamed to filename.mp4.crdownload, and the download will continue.

However, in case you already have downloaded filename.mp4, then chrome will ask you whether you want to download the file again. If you ignore the infobar, the temporary file will not be deleted. If you click "x" or confirms the download, the temporary file will be removed or renamed to filename(2).mp4.crdownload.

So the issue reported in #9 is that some of the infobar popups are not properly closed (they can be hidden beneath another popup, or if you scroll up the page), thus leaving the temporary file on the sdcard and without continuing the download

Thank you, can we create files with name:

filename.extension_such_like_mp4.download
filename(2).extension_such_like_mp4.download
filename(3).extension_such_like_mp4.download

on the beginning of start and later only remove ".download" when download is completed?

Once the filename is determined, they will be renamed to the file names above. 

However, if user doesn't ack the infobar, i don't think the actual file name matters too much as the download won't be able to finish. One thing we can do is to clean up the temporary files if user doesn't take any action on the infobar, but that may happen when browser restarts

I'm not sure if I understand correctly #15, but...

the clue of this bug is that I was left with many .com.google.Chrome.SOMEID files in Downloads directory (they were downloaded in 100%) and ideally I would like to have 

filename.extension.download
filename(2).extension.download
filename(3).extension.download

or 

filename.extension
filename(2).extension
filename(3).extension

files instead of them. 

I don't think that adding new processes / new code on browser startup is perfect idea, but I think, that we should at least eliminate weakness, which is having totally unnamed files (.com.google.Chrome.SOMEID).

Do you agree? Can we do it?

If user has acknowledged on the infobar, the file name will be changed to filename(xx).extension.crdownload automatically (if user choose to continue).

If user hasn't interacted with the infobar, then it is very likely he don't want to save that file. So cleaning it up when the infobar is closed or when the next time chrome starts is more appropriate behavior.

Leaving a filename(xx).extension.crdownload will not help, and also it confuses Chrome about whether this is a temporary file, or a file is in the middle of download.

Currently Chrome cleans up the temporary files when infobar is closed or user rejects the duplicate download on the infobar. However, if Chrome is killed before user interacts with the infobar, then it need to clean up those temporary files on next startup.

> Currently Chrome cleans up the temporary files when infobar 
> is closed or user rejects the duplicate download on the infobar. 

I don't agree, I have clicked 3x on Download video (new context menu) and closed infobar by clicking "x" (2 were hidden by Chrome somehow), 2 files were not deleted, was was renamed.

> However, if Chrome is killed before user interacts with the infobar, 
> then it need to clean up those temporary files on next startup.

hmmmm, I don't like it, from the second hand on my phone it will not be painful in terms of CPU cycles, 

there is still question about names - when you have 20 files and you decided to recover something from them, you have to check every of them.

> Leaving a filename(xx).extension.crdownload will not help, 
> and also it confuses Chrome about whether this is a temporary file, 
> or a file is in the middle of download.

Chrome shouldn't be confused just because of filename, if it happens, we have even more serious problem.

Hi,

Do we have any progress or decision here?