1782366 - M4B File Extension is being changes to m4a/3gp

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect, P2)

Description

[Kunal]

Firefox for Android

Steps to reproduce:

Case 1

1. Head to librivox.org
2. Open any available AudioBook. (I used 15th Anniversary Collection)
3. Scroll down & Click "M4B Audiobook" located at left hand-side under Links Sections
4. Redirects & Start Downloading the file

Case 2
Note: The above mentioned file was Downloaded & Uploadedto Gdrive using Chrome

1. Open Google Drive & Navigate to folder where the AudioBook is uploaded
2. Right Click the file & start downloading it
3. The file starts downloading
   Add Note: Case 2 Seems to present in Firefox for Android too

Actual results:

Case 1: The file type (extension) was changed to 3gp for the downloaded file
Case 2: The file type (extension) was changed to m4a for the downloaded file

Expected results:

Case 1: The file type (extension) remains unchanged for the downloaded file
Case 2: The file type (extension) remains unchanged for the downloaded file

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Kunal]

Was further testing & found that if download files from here (https://archive.org/download/tom_sawyer_librivox/AdventuresOfTomSawyer-64kb-Part1_librivox.m4b) the m4b files are saved as MP4.

What is different was somehow the file above started playing & had to be manually downloaded where in reported case 1 above (https://archive.org/download/15thanniversarycollection_2008_librivox/15th_anniversary_librivox.m4b) the file started downloading as 3gp without playing.

Also, here is my handlers.json:

{"defaultHandlersVersion":{},"mimeTypes":{"application/pdf":
{"action":3,"extensions":["pdf"]},"image/webp":{"action":3,"extensions":
["webp"]},"image/avif":{"action":3,"extensions":["avif"]},"text/xml":
{"action":3,"extensions":["xml","xsl","xbl"]}},"schemes":{"mailto":
{"stubEntry":true,"handlers":[null,
{"name":"Gmail","uriTemplate":"https://mail.google.com/mail/?extsrc=mailto&url=%s"}]},"vscode":{"action":4,"ask":true}},"isDownloadsImprovementsAlreadyMigrated":true,"isSVGXMLAlreadyMigrated":true}

Also, in default apps for File type in W10, VLC has been set as default type for m4a & m4b.

Comment 3

[Alex Cornestean]

Hello and thank you for reporting this issue !

As the issue does not appear to occur due to any installed add-ons, it seems the problem is with the browser itself. I’ll change the product to better reflect this and thus involve the appropriate team.

Thank you !

Comment 4

[:Gijs (out for now; he/him)]

Given that different m4b files are doing different things there must be at least some interaction with the media sniffing code...

Paul or Alastor, could you take a look at what's happening here?

Comment 5

[Alastor Wu [:alwu]]

Here is what I found by doing a quick investigation.

Take files in the comment2 as examples. By using mp4Box to check the ftyp box, the first file has brand mp42 which means MP4 v2. And the second file has brand M4A. Both of these two files are not M4B actually, the original file extension are not correct for them. In addition, based on the ftyp list, m4b should use audio/mp4 as its mime type.

Therefore, for the first file, using mp4 makes sense to me. But for the second file, using 3gp is apparently wrong.

Comment 6

[Alastor Wu [:alwu]]

So I have a patch to fix the incorrect 3gp mimetype. After applying that, the first file and the second file in comment2 would be mp4 and m4a. But those file use the extension m4b which is different from what we get.

m4b is a longer version of m4a so if marking them as m4b also makes sense, even if it's different from their major types (but they both have m4a as a compatible type)

Gij, do you know what mechanism we use to determine the final file extension for a download file? Is that simply depend on the content type that the media sniffer returns? I saw something like this and I wonder if we have other ways to overwrite the extension type again?

Eg. file extension is m4b, sniffering if m4a but we know m4b is equal to m4a so we would still use m4b as the extension for download file

Comment 7

[:Gijs (out for now; he/him)]

I think I answered in bug 1772988 comment 13 - let me know if anything is still unclear!

Comment 8

[Alastor Wu [:alwu]]

Yes I still have some questions about the process of determining the final extension type.

For example, here are the log when we have a mime type audio/mp4 on MacOS,

2022-08-12 18:42:22.810523 UTC - [Parent 34522: Main Thread]: I/HelperAppService Getting mimeinfo from type 'audio/mp4' ext ''
2022-08-12 18:42:22.810550 UTC - [Parent 34522: Main Thread]: D/HelperAppService Mac: HelperAppService lookup for type 'audio/mp4' ext ''
2022-08-12 18:42:22.812070 UTC - [Parent 34522: Main Thread]: D/HelperAppService LSCopyApplicationForMIMEType found a default application
2022-08-12 18:42:22.812354 UTC - [Parent 34522: Main Thread]: D/HelperAppService OS gave us: type 'audio/mp4' found '1'
2022-08-12 18:42:22.812362 UTC - [Parent 34522: Main Thread]: I/HelperAppService OS gave back 0x2b5cbe500 - found: 1
2022-08-12 18:42:22.812367 UTC - [Parent 34522: Main Thread]: I/HelperAppService Searched extras (by type), rv 0x00000000
2022-08-12 18:42:22.812420 UTC - [Parent 34522: Main Thread]: I/HelperAppService MIME Info Summary: Type 'audio/mp4', Primary Ext 'mp4'
2022-08-12 18:42:22.812429 UTC - [Parent 34522: Main Thread]: I/HelperAppService Type/Ext lookup found 0x2b5cbe500
2022-08-12 18:42:22.813664 UTC - [Parent 34522: Main Thread]: I/HelperAppService Enabled hashing and signature verification
2022-08-12 18:42:27.123337 UTC - [Parent 34522: Main Thread]: I/HelperAppService nsExternalAppHandler::OnSaveComplete
  aSaver=0x131db5980, aStatus=0x804B0002, mCanceled=1, mTransfer=0x0
2022-08-12 18:42:28.205090 UTC - [Parent 34522: Main Thread]: I/HelperAppService nsExternalAppHandler::OnStopRequest
  mCanceled=1, mTransfer=0x0, aStatus=0x804B0002

From above log, I don't understand why audio/mp4 would be mapped to mp4? I thought it should be m4a?

---

If I understand the process correctly, nsExternalAppHandler would be used in two situations,
(1) the mimetype which isn't supported to be opened in the browser directly
(2) the mimetype which is supported to be opened in the browser directly, and then a user is going to download the file from a menu later

So nsExternalAppHandler would receive a mime type and use that to find a mapping extension type. The process seems like this, searching that by an designed order. After that, we might also overwrite the extension type if the type is in our list.

Is my above understanding correct?

---

In addition, I tried to do some hack for debugging. Take AUDIO_MP4 as an example, I tried to tweak its value to AUDIO_MP4, "foo", "bar"}. Then when I download the file, I can see the file description is bar as I expected, but the extension type is still mp4 not foo. I wonder why? Is the OS level already determining the type?

---

Last problem is an open question. For the files in comment2, those two files are not specified as a m4b in their mp4 container. (they are mp4 and m2a) In this situation, when downloading them, should we respect the type we sniffered, or use their original extension type?

Thank you.

Comment 9

[:Gijs (out for now; he/him)]

I'm going on PTO but in my absence perhaps Neil can help answer the questions in comment 8. Otherwise I'll do my best to answer them on my return.

Comment 10

[Neil Deakin]

On my Mac system the OS returns 'mp4' as the extension for 'audio/mp4', so this is added as the first valid extension. However, the table in extraMimeEntries is consulted and this adds the 'm4a' extension as a valid extension. So any filename that ends with 'mp4' or 'm4a' should be accepted as is when 'audio/mp4' is the content type. 'm4b' is not included so is considered an invalid extension for audio/mp4 -- a filename with this extension will be replaced with the first extension 'mp4'.

All this is assuming from your comments that since the files in comment 2 are actually sent as 'application/octet-stream' , that the patch mentioned in comment 6 is adjusting the type to 'audio/mp4'.

Is the issue here that we just need to add 'm4b' as an additional valid extension to the extraMimeEntries for 'audio/mp4'?

Comment 11

[:Gijs (out for now; he/him)]

Thanks for checking this Neil! I think bug 1772988 will just fix this now? Clearing my needinfo, lmk if there is more to do here to address the issue.

Comment 12

[Adrian Florinescu [:aflorinescu]]

Latest Nightly 106.0a1 (2022-09-07) and ESR 102.3.0, still getting 3gpp on windows amd 3gp on Mac. Test m4b

Comment 13

[Neil Deakin]

Yes, as I indicated, the patch mentioned in comment 6 (which hasn't been posted anywhere) is also still needed to fix this bug.

Comment 14

[Alastor Wu [:alwu]]

One of my previous question in comment8 is that I tried to tweak the type for extraMimeEntries which didn't work. That made me not be able to download file a m4b. (after applying my patch). But now I see your patch in bug 1772988 fixes the issue.

---

So the current problem is that, do we always need to trust the brand type in mp4 ftyp box?

• File no.1
  AdventuresOfTomSawyer-64kb-Part1_librivox.m4b
  Major brand : mp42 (MP4 v2) -> mime type would be video/mp4 (wrong! that results in download type becoming .mp4)
  Compatible brand : M4A,mp42,isom

• File no.2
  5th_anniversary_librivox.m4b
  Major brand : M4A -> mime type would be audio/mp4 (ok!) -> by bug 1772988, we can deduce m4b from mime type.
  Compatible brand : 3gp5,isom

Above files don't have a correct major brand in their ftyp box, one of them would result in a wrong mime type. Paul, when the brand in ftyp is not correct, do we have any good way to determine what the correct mime type should be for files?

Comment 15

[Alastor Wu [:alwu]]

Okay, I talked to Paul today, and I think I have an idea about how to fix this.

First, what Paul did in bug 1704115 is to always sniffing media resources, which follows what the spec says.

To determine the format of the media resource, the user agent must use the rules for sniffing audio and video specifically.

But always sniffing media resources causes a new problem, which is the media resource is wrong with its mime type when we inspect its content. Comment 14 is an example. That results in returning an incorrect mime type which causes Firefox renaming the extension during the process of mime type mapping.

From this chapter of spec, it says that once media matches the pattern of mp4, we should return video/mp4 no matter the resource is audio or video or not. That makes me feel that we should be tolerant mapping audio extension to video/mp4.

Comment 16

[Alastor Wu [:alwu]]

Attachment: Bug 1782366 - part1 : don't use space in the pattern.

Comment 17

[Alastor Wu [:alwu]]

Attachment: Bug 1782366 - part2 : mapping audio extension to 'video/mp4' as well.

Depends on D157684

Comment 18

[:Gijs (out for now; he/him)]

:alwu, what's blocking the patches here from getting review and landing / what are the next steps? :-)

Comment 19

[Alastor Wu [:alwu]]

Sorry for late reply, after an offline discussion with Gij last time, I already requested review for those patches.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cc2151d227bf
part1 : don't use space in the pattern. r=padenot
https://hg.mozilla.org/integration/autoland/rev/18d5cc3c3f87
part2 : mapping audio extension to 'video/mp4' as well. r=padenot

Comment 21

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/cc2151d227bf
https://hg.mozilla.org/mozilla-central/rev/18d5cc3c3f87