Chrome does not support the mpeg4 codec, so we shouldn't open this file in Chrome -- though I don't know if the intent provides enough information to determine this.

I just tried this out. If you initiate playback from the downloads home, it does the right thing and intents out. However, if you click on the notification or the toast, it drives you to the Chrome custom tab with the video which won't play. It looks like we have a disconnect in our logic of whether to intent or play in Chrome. 

This could block M55, so I am increasing the priority. Dan isn't back until next week. Min if you have time, could you take a look at this?

 Issue 657596  has been merged into this issue.

Jon, have you tried the latest Dev?

You should see the same behavior when clicking the snackbar or downloads home.The change went in last friday.

However, there is no good solution to this. The problem is that the download link has a MIME type "application/force-download", since the file actually has .mp4 extension, Chrome will automatically remap the MIME type to "video/mp4", which is a supported MIME type with chrome's release build: https://cs.chromium.org/chromium/src/media/base/mime_util_internal.cc?sq=package:chromium&dr=CSs&rcl=1476847656&l=419

This can happen without MIME type remapping. Say a web site hosts some .flac audio files, but it names the download .mp3. In that case, Chrome will download the mp3 file and try to open it by itself, but ends up failing.

Thanks Min, I am using Canary 56.0.2894.0 from yesterday, so it should have the change shouldn't it? 

I have a question on your latter comment. It seems that downloads home does have the right behavior? Are you highlighting that even though this case does work correctly that other cases might not?

I see, there is another bug in downloads home.

when clicking a download in downloads home, it uses the download GUID to query the download item. And using the GUID, the download history will return "application/force-download", thus causing the download home to generate an intent and pass it to other media players. 

we should use the remapped MIME type, rather than the generic MIME type.

Re #1: dalecurtis@: certainly Chrome knows how to play back MP4 files. They constitute something like 80% of the videos we see on mobile and are the primary target for Flywheel's video optimization. Or do you mean something different by "mpeg4 codec"?

Re "there is no good solution to this": UC Browser has no problem with these files, so clearly there is a solution. Why can't the file type be detected based on the content?

@mdw, I was referring to mpeg4 the codec (less commonly known as h263), not mp4 the container -- confusing I know :)

mpeg4 (h263) codec: https://en.wikipedia.org/wiki/H.263
mpeg-4 container: https://en.wikipedia.org/wiki/MPEG-4_Part_14

We only support h264 in the mp4 container, not h263. FWIW, even in BRIC h263 rates are ~0.22%:

https://uma.googleplex.com/histograms/?endDate=20161018&dayCount=1&histograms=Media.VideoCodec&fixupData=true&showMax=true&filters=platform%2Ceq%2CA%2Ccountry%2Cone_of%2CBR%7CIN%7CRU%7CCN%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

Unless there's a really strong case, and usage data suggests there isn't, we won't add support for this codec given the risk of stagefright type vulnerabilities.

Re #8, mp4 is a container, it could be using a lot of video codecs, so a file named video.mp4 doesn't necessarily mean it is supported in Chrome, although it is likely supported by Android.

Now this goes back to the UI design. When clicking an mp4 file on notification or downloads home, should we open it in Chrome? Or we should fire an intent to launch another app to play it? Our recent UI change favors the former option. 
But then, it could fail because it is using an unsupported Codec. 

One possible way to solve this is to Check the codec being used when user clicks the download notification, and fires an intent only if the codec is not supported by Chrome. But this will not be a trivial change

Dale: Makes sense, thanks :-)

Qin: I'll let Jon decide what the right flow should be, but it seems to me that opening a file in the Downloads menu or the Notification should do the same thing for the same file. In the case of one supported by Chrome, it should play back in Chrome. In the case of a file not supported by Chrome, it should intent out.

Problem #1, clicking on the video from any UI should perform the same action. From talking to Min, it seems like we have a fix in place to fix that issue. This is the release blocker for M55. Min, can you confirm that this is fixed.

Problem #2, right now we only use the mime type to determine whether or not we can play the video. In this case, Chrome would try to play the video back in Chrome and would fail (ironically, there is a separate bug that caused the downloads home to intent out, which is technically incorrect, even though it had the desired behavior). We need to check the codec prior to, or at the time of, playback, so that we can intent out if we cannot actually render the file. Unsupported .mp4 files are fairly rare, so we won't block M55 on this. Additionally, the fix is likely to be more significant, so I have opened a separate bug with a different milestone. https://bugs.chromium.org/p/chromium/issues/detail?id=658290

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

commit 1ff89f652baf6e0397c946d76371a04fdda754a0
Author: qinmin <qinmin@chromium.org>
Date: Tue Oct 25 01:09:48 2016

Fix an issue that opening a download with remapped MIME type will launch an intent

When a download's MIME type is remapped, Chrome should use the new MIME
type.
However, when opening a download from download home, GUID is used to
find the download.
The download history stores the original MIME type, which is not
remapped.
This causes Chrome to incorrectly launch an intent even if the type is
supported.

BUG=657594

Review-Url: https://codereview.chromium.org/2437243002
Cr-Commit-Position: refs/heads/master@{#427205}

[modify] https://crrev.com/1ff89f652baf6e0397c946d76371a04fdda754a0/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java
[modify] https://crrev.com/1ff89f652baf6e0397c946d76371a04fdda754a0/chrome/android/java/src/org/chromium/chrome/browser/download/ui/BackendProvider.java
[modify] https://crrev.com/1ff89f652baf6e0397c946d76371a04fdda754a0/chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java
[modify] https://crrev.com/1ff89f652baf6e0397c946d76371a04fdda754a0/chrome/android/javatests/src/org/chromium/chrome/browser/download/ui/StubbedProvider.java
[modify] https://crrev.com/1ff89f652baf6e0397c946d76371a04fdda754a0/chrome/browser/android/download/download_manager_service.cc

Your change meets the bar and is auto-approved for M55 (branch: 2883)

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

commit dbc136f566c97a2f75aff133b537d1c52fae148b
Author: Min Qin <qinmin@chromium.org>
Date: Tue Oct 25 18:19:38 2016

Fix an issue that opening a download with remapped MIME type will launch an intent

When a download's MIME type is remapped, Chrome should use the new MIME
type.
However, when opening a download from download home, GUID is used to
find the download.
The download history stores the original MIME type, which is not
remapped.
This causes Chrome to incorrectly launch an intent even if the type is
supported.

TBR=dfalcantara@chromium.org
BUG=657594

Review-Url: https://codereview.chromium.org/2437243002
Cr-Commit-Position: refs/heads/master@{#427205}
(cherry picked from commit 1ff89f652baf6e0397c946d76371a04fdda754a0)

Review URL: https://codereview.chromium.org/2451633004 .

Cr-Commit-Position: refs/branch-heads/2883@{#287}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java
[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/android/java/src/org/chromium/chrome/browser/download/ui/BackendProvider.java
[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java
[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/android/javatests/src/org/chromium/chrome/browser/download/ui/StubbedProvider.java
[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/browser/android/download/download_manager_service.cc

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

commit dbc136f566c97a2f75aff133b537d1c52fae148b
Author: Min Qin <qinmin@chromium.org>
Date: Tue Oct 25 18:19:38 2016

Fix an issue that opening a download with remapped MIME type will launch an intent

When a download's MIME type is remapped, Chrome should use the new MIME
type.
However, when opening a download from download home, GUID is used to
find the download.
The download history stores the original MIME type, which is not
remapped.
This causes Chrome to incorrectly launch an intent even if the type is
supported.

TBR=dfalcantara@chromium.org
BUG=657594

Review-Url: https://codereview.chromium.org/2437243002
Cr-Commit-Position: refs/heads/master@{#427205}
(cherry picked from commit 1ff89f652baf6e0397c946d76371a04fdda754a0)

Review URL: https://codereview.chromium.org/2451633004 .

Cr-Commit-Position: refs/branch-heads/2883@{#287}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java
[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/android/java/src/org/chromium/chrome/browser/download/ui/BackendProvider.java
[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java
[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/android/javatests/src/org/chromium/chrome/browser/download/ui/StubbedProvider.java
[modify] https://crrev.com/dbc136f566c97a2f75aff133b537d1c52fae148b/chrome/browser/android/download/download_manager_service.cc

Download home should now have the same behavior as clicking on the snackbar.

For video codec issue, that is tracked in crbug/658290, closing this now

[Automated comment] removing mislabelled merge-merged-2840

[Automated comment] removing mislabelled merge-merged-2840

This is still broken for me in M58. I can download the file in Chrome, but I can't play it back.

Example video link where I see this behavior:

https://dl.pagal.link/upload_file/367/Bollywood%20Video%20Songs%20n%20Trailers/Bollywood%20Video%20Songs%20n%20Trailers%202017/Trapped%20%282017%29%20HD%20Video%20Songs/Dheemi%20-%20Trapped%20-%20HD%20Video%20Song/Dheemi%20-%20Trapped%20-%20MP4.mp4

Note re: #22: This video playback is broken whether you tap on the link from Downloads Home or from the notification.

The video codec issue is still a WIP. closing this for now as this is already tracked in crbug/658290

Well, technically this bug is not fixed; the video playback is broken, but it's blocked on the other bug. So I'll label it that way. I think it's useful to ensure that we don't mark bugs as fixed when they aren't, in fact, fixed :-)

updating labels and dropping pri since no one seems to be working on this.