1828441 - MP4 containers served with "content-type:application/octet-stream" are not downloaded

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Gian-Carlo Pascutto [:gcp]]

1. I'm serving .mp4 files with H265 video tracks from my own server. This extension is served with content-type:application/octet-stream because the files need to be downloaded, not played.

2. General->Applications->MPEG-4 Video is set to Save

3. What should Nightly do with other files? -> Save files

4. Enter an URL in the address bar pointing to such a file

Actual:

Error message "No video with supported format and MIME type found".

Media resource https://......mp4 could not be decoded. 
Media resource https://.......mp4 could not be decoded, error: Error Code: NS_ERROR_DOM_MEDIA_DEMUXER_ERR (0x806e000c)
Details: virtual RefPtr<MP4Demuxer::InitPromise> mozilla::MP4Demuxer::Init(): No MP4 audio () or video () tracks ....mp4

Expected:

File is downloaded and saved.

Testing with Chromium on Linux (i.e. no hardware H265 decoding) shows that Chrome downloads the file. Testing with Chrome on Windows on a machine with H265 decoding shows that Chrome downloads the file. (I verified that Chrome can play the file when it's dropped onto it). Given that Firefox is configured to Save MPEG-4 Video files, the behavior makes no sense.

Comment 1

[:Gijs (he/him)]

I think this is a result of the fact that the code that determines what to do with the file doesn't see application/octet-stream, but sees the result of the media sniffer's sniffing, which won't be that. And because there is (presumably) no content-disposition: attachment header, we don't download but attempt to play the file instead (because at that point, to docshell, it will just look like a media file).

Fixing this would involve having the media sniffer to either not sniff for items not loaded as toplevel documents, and/or not replacing application/octet-stream (either ever, or in that case). A testcase would probably be helpful for this.

Over to Core :: A/V as the media sniffing code is not on the front-end team's radar.

Comment 2

[Paul Adenot (:padenot)]

We're currently designing a plan to fix this. We need to demux the file a little bit to understand that we need to offer it for download, but it should be doable.

Comment 3

[Jim Mathies [:jimm]]

This doesn't need to be S2, but FYI we are working on this currently.

Comment 4

[az [:az]]

Attachment: Bug 1828441 - Part 1 - Disable media sniffing when navigating directly to files served as application/octet-stream r=padenot

Comment 5

[az [:az]]

Attachment: Bug 1828441 - Part 2 - Add download verification test for media files served as type application/octet-stream r=padenot

Depends on D188505

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/72c06e1b962b
Part 1 - Disable media sniffing when navigating directly to files served as application/octet-stream r=padenot
https://hg.mozilla.org/integration/autoland/rev/b690bf927faa
Part 2 - Add download verification test for media files served as type application/octet-stream r=padenot

Comment 7

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/72c06e1b962b
https://hg.mozilla.org/mozilla-central/rev/b690bf927faa

Comment 8

[az [:az]]

Release Note Request
[Why is this notable]: Directly navigating to media files served as type application/octet-stream will no longer have their MIME types overridden by the media sniffer, allowing these files to be downloaded instead of attempting playback.
[Affects Firefox for Android]: Yes
[Suggested wording]: Media sniffing disabled for toplevel documents served as type application/octet-stream
[Links (documentation, blog post, etc)]: -

Comment 9

[Donal Meehan [:dmeehan]]

Thanks, added a note to the Fx119 Nightly release notes. Keeping the relnote? flag open to keep it on the radar for inclusion in our final release notes.