michael.heuberger.binarykitchen@ Thanks for the issue.

Able to reproduce this issue on Mac OS 10.12.6, Windows 7 and Ubuntu 14.04 using the latest Stable 61.0.3163.100, but unable to reproduce this issue on the latest Canary 63.0.3233.0.

Performed reverse bisect and below is the Bisect Information.

Reverse Bisect Information:
=====================
Good build: 62.0.3164.0  
Bad Build : 61.0.3163.116.

Note: As the good and bad builds are from different milestones and the bad build is a branch build, cannot execute the per-revision script for finding the Suspect CL.
Hence through Manual Bisect providing the Changelog URL from Omahaproxy.
Below is the 

Change Log URL :
==================
https://chromium.googlesource.com/chromium/src/+log/61.0.3163.0..62.0.3164.0?pretty=fuller&n=10000

As we are unable to find the right suspect from the above ChangeLog, requesting someone from Dev to look into the issue.
Hence marking this issue as Untriaged for further update from Dev.

Adding ReleaseBlock-Stable as this is a recent regression. Please feel free to remove if this is not the case.

Thanks..

Can't reproduce on trunk on Ubuntu 14.04. The file name extension is generated mainly based on mime type. The mime type currently for this URL is video/webm, which seems to be correct.

In the bisect, one CL changed the mime type and file name generation code, which looks suspicious.
https://chromium-review.googlesource.com/578649

I think commit 	77132a2bc78e8dc9ce411e8166bfd009f6476f6f actually fixed this issue.

Mark this as won't fix, since 62 stable is approaching, we probably don't want this fix in 61? Feel free to change it back if we do need the fix commit for 61 stable.

Also I checked our android code, which we use android::GetMimeTypeFromExtension which uses some Java library, so this bug should not affect android.

one second. have two more questions:
- is there really unit test coverage to make sure this won't happen again?
- still unanswered: how the HTML markup can set it's file name? currently it's always called 'download'

To michael.heuberger.binarykitchen@,

1. We have filename_util_unittest.cc but coverage may not be good. I'll dig a bit more on that test.

2. <a> download attribute should work for normal download. But I'm not sure if there is any standard in html to specified a video download name.

In Content-Disposition HTTP response header, there is a filename params that can be specified. This should be a reliable way to let Chrome to generate the correct extension.

Also the URI in <source> is used by Chrome, but the last component in the website doesn't look like an extension, so the file name generation logic is probably not recognizing it as file name. It might be helpful to change the URI to something like:

<source src="movie.mp4" type="video/mp4"> And Chrome will figure out the file name from URL, if there is no content disposition in the response header.

sweet, yeah please ensure solid unit test coverage here.

about the Content-Disposition HTTP response header, yeah, that fixed it. thanks for pointing to this.