Sniff format of media files loaded in a tab
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
People
(Reporter: 08xjcec48, Unassigned)
References
Details
Attachments
(1 file)
|
3.91 MB,
audio/mpeg
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0
Steps to reproduce:
Tried streaming an AAC audio file that has been uploaded as wrong_extension.mp3 to a site that doesn't inform its correct content-type.
The file was loaded from https://example.com/wrong_extension.mp3.
Actual results:
No video with the supported format and MIME type found.
Expected results:
Firefox can actually play the file on my system if I upload them with the .aac and .mp4 extensions.
Firefox could do the same as Chromium browsers and check the actual codec for files with the .mp3 extension instead of just giving an error.
Users who don't know about codecs might think that Firefox is broken.
Note that the file is played on this Bugzilla page, but if you open it in another tab, it gives the same error.
|
||
Comment 2•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 3•3 years ago
|
||
As we only support AAC in mp4, ADTS and 3GP, putting it on MP3 is not valid. However, we would do sniffing to check whether media format is correct.
When file directly gets played via bugzilla, I can see sniffing work and use mp4 demuxer. But when I open file directly, sniffing doesn't work. I wonder maybe there are some differences between loading it directly via HTMLMediaElement and via a MediaDocument. Paul, do you have any thought about this? Thanks!
Playing the same file from a local drive on Windows also works.
|
||
Comment 5•3 years ago
|
||
This is a bug in Chrome that downloads .mp4 dash files as .mp3, because of their horrible probe engine, that does not see ISO's container atoms.
Alastor, can you please look into this again? The developer you've pinged never replied.
|
||
Comment 7•8 months ago
|
||
Ashley has done some work in the area, she can probably take a quick look. Ashley, istr there is some specific logic when loading the file directly, it would be ideal to align it (remove the special case), so that those files would play.
This fails to play for me on Bugzilla regardless of whether I open the attachment in a new tab or click through directly, but it does play if I load the file locally. When the file is served on Bugzilla, it's being served with x-content-type-options: nosniff. When the file is served locally, it is not. We obey nosniff during the call to ValidateMIMEType() here. If I comment the call out, sniffing goes through and the file plays back as expected on Bugzilla. I'm not sure what the best fix here would be, since AFAIK we're doing the right thing by obeying the server headers. Would you have any thoughts :padenot ?
|
|
||
Comment 9•8 months ago
|
||
I don't think we want to honor nosniff if not in a web context (e.g., opening the file stand alone).
|
||
Comment 10•7 months ago
|
||
Have you run into any instances where you encounter this behavior on a site where x-content-type-options: nosniff isn't present in the headers? If so, could you please provide me with a link? Thanks!
|
Reporter | |
Comment 11•7 months ago
•
|
||
Thank you for looking into this. Bugzilla used to show an audio player on this page, but it no longer does. It likely lacked the nosniff header.
I never mentioned the original link because it was from a temporary file host, but it's safe to assume it had the nosniff header to prevent attacks.
Since sniffing is expected to be blocked by nosniff, I'm closing this bug as WORKSFORME.
Description
•