I am not able to repro on my device, the file downloads as expected. I am running 56.0.2894.0. Downloads folks, can you please try the video and see if you can repro? 

I think the problem is that android DownloadManager is not disabled on your chrome.

go to Chrome://flags to disable it

Qin: Why should I have to flip a flag manually to get the desired behavior? Users cannot be expected to do that.

You duped this against a fixed bug. The bug has not been fixed because I'm having this issue. Reopening.

have you tried disabling the DownloadManager through chrome://flags? and does the download happen?

Re #4: I don't know which flag to disable. I set the flag "Enable downloads manager UI in the app menu" to "Disabled" as well as "Enabled" and I get the behavior reported in the original bug report, above. So that flag has no effect.

You didn't answer my question about why changing flags should be necessary.

Sorry, I Just checked M55, the CL for defaulting all downloads to Chrome made into that branch, so no flag is required.

Since all downloads goes to Chrome, the problem you described sounds more like a external protocol handling. However, I cannot reproduce the problem on my nexus 6P with NBD90X. Can you go to chrome://net-export and capture the network log and post it here?

Here's a netlog from hitting the [Download File] link from this page:

http://pagalworld.co/filedownload/11241/102444/Rock%20On%20Revisited%20-%20Rock%20On%202%20-%20Video%20MP4.html

Which seems to be:

http://dl.enjoypur.vc/upload_file/367/382/7491/PagalWorld%20-%20Bollywood%20Mp4%20Video%20Songs%202016/Rock%20On%202%20(2016)%20Mp4%20Video%20Songs/Rock%20On%20Revisited%20-%20Rock%20On%202%20-%20Video%20MP4.mp4

Deleted: net_internals_log2 4.2 MB

net_internals_log2 4.2 MB View Download

wierd, I didn't see any urlrequest for the mp4 file in the netlog

That's because Chrome is intenting out the MP4 is being loaded by a separate app (I loaded it in MX Player in this case).

So looks like this is a case of navigation throttling. It is very strange that it doesn't happen on my device, need to check why

What is navigation throttling?

So here is what happens:
the anchor element doesn't have a download attribute. As a result, clicking on it should normally opening a standalone video document in Chrome.
However, since Chrome cannot decode the video, so the navigation falls back to the throttller, which queries any app that can handle the url before Chrome tries to download it.  MX Player happens to declare that it can http mp4 files, so an intent is fired to launch MX Player. If MX player is not installed, Chrome will start downloading it.

Navigation throttling:
Chrome allows url navigation to be handled by other apps.
For example, clicking on a url with external protocols, e.g map://, should launch the google maps app, same for tel://. Notice that this is not limited to external protocols, it also applies to http and https protocols. 
However, not all urls will be throttled. If the url can be handled by Chrome, then there is no need to throttle it. Also we don't throttle pdf urls.

However, Navigation throttling is prone to errors as other cannot access auths and cookies. So it could fail in some cases.

Re #11: Thanks for the clarification.

How does Chrome know it can't handle this file without trying to access the URL first? (Since I don't see it in the netlog, I assume Chrome didn't try to access it at all, but maybe that's wrong.)

In UC Browser, tapping on any video link gives you the option of downloading or watching the video. Here we seem to be deciding not to download it via Chrome, because we won't be able to play it.

Jon, I think this is a product question for you -- would it not be better for Chrome to be the download manager of choice, even for content that would require intenting out to view?

For this case, the MIME type "application/force-download" causes Chrome to stop access the url. The navigation throttler should respect that particular MIME type and treat it as a download, however seems there is a bug in our code.

Now back to video downloading/watching. Downloading a video is not a good experience most of the time. If user just interested in a 5 seconds peek of the video, downloading the whole content will be a waste of time and data. However, as I mentioned before, this could result in playback errors as video player cannot access user cookies.
For pdf, chrome always download the pdf first, before opening it with pdfviewer. This is because pdf file is small, and stream viewers doesn't save too much data.

Well, this MIME type (application/force-download) suggests that it should be *downloaded*, not watched, so it would not be surprising for users, I think, to have Chrome download the content in these cases.

UC Browser solves this by prompting the user to either download or play the video when they tap such a link.

 

In emerging markets, downloading the video is very often the default preference for the user because playback is sometimes not possible on a 2G network.

mdw@ to answer your product question, yes, we should download all content regardless of whether we can play it or not. Our system is designed to handle those cases where we cannot play. 

We are looking at potential UX improvements on how to give users more control over the download vs. playback experience, but there aren't any changes on the horizon at this time.

Re #17: Can you summarize what the action item on this bug is, then? Is the idea to download the video rather than try to play it back? Should this be done in all cases, or only on slow networks?

Ping. This is still broken for me in M56.

The problem is not easy to fix.

Intercept navigation throttler comes before response headers are received. Therefore, the mime type("application/force-download") is unavailable  when intercepting the navigation.
So if an app claims that it can handle a http url with mp4 extension, Chrome will launch an intent.

The proper fix will need to let Chrome wait until response header is received. Need to investigate the impact of doing this

Note that UC Browser works fine on this, and this is one of the most popular Indian media sites according to Google search logs. I suggest that we prioritize fixing this one way or another. Jon?

Cleaning up CC list.

So, when I try this on M56 dev, the file downloads as intended. Matt are you saying the file won't download or are you having an issue with playback?

I am not sure if pagalworld.co changed things, but this now works for me on 56.0.2924.13. Did anything change between that version and whatever M56 I would have been running on November 18? Or did the site change?

Note that the video does not play after being downloaded in Chrome, which seems to be a regression of  crbug.com/637917 .

Based on my understanding of the issue, this isn't a regression of crbug.com/937917. That bug gave an error when the file name had spaces. In this case it looks to be an instance of crbug.com/658290 where the file type is supported, but the codec isn't, so you just get a black screen. Currently the downloads home only looks at the mime type and there is no easy way to determine whether the codec is supported. 658290 tracks the work to use the codec as part of the logic in determining whether to play or intent. Given that the download experience is working correctly, I suggest we close this bug as fixed and track the remaining work in 658290.

Possible. Do we know for sure that this is due to an unsupported codec though?

And why are we not supporting this codec, when UC Browser does?

In this case, yes. crbug.com/657594 goes into the gory details. This uses h.263 codec in an .MP4 file. UC and Android support this codec, Chrome doesn't because:
-There are potential security issues with this codec
-There is a royalty associated with this codec
-H.263 is very rarely used - .22% of videos in BRIC countries.

Thus, similar to your wikipedia bug, this falls into a bucket of a very rarely used file format showing up on a very popular site. Despite that, I don't think there is sufficient evidence to provide support. However, leaving the user staring at a blank screen is a bad experience. That is what we need to fix.

Got it, makes sense. Marking this as fixed given that crbug.com/658290 addresses the underlying issue.