Important, this bug only occurs in the Flatpak build of Firefox (and possibly the Snap, not sure how MIME types are handled there).

I've attached a small extension that reproduces the bug:

• The extension contains a file "pop.flac"
• The extension page "index.html" (opened automatically) tries to load the pop.flac file into an audio element (new Audio, src set to the return value of runtime.getURL)

What happens is that the loading fails in the Flatpak version of Firefox:

HTTP “Content-Type” of “application/x-unknown-content-type” is not supported. Load of media resource moz-extension://b920bd4a-df19-4d21-b433-3297132eec05/pop.flac failed. index.html
Cannot play media. No decoders for requested formats: application/x-unknown-content-type index.html

However, if the FLAC file is opened in a separate tab, it can be played just fine (see link at the bottom of index.html).

This isn't the first time that I've seen inconsistent MIME handling in extension pages for audio, but it's the first time I've been able to reproduce it fully myself.

Oh, also important, to load the extension temporarily in the Flatpak version of Firefox, make sure to load the zipped version...

Since the Flatpak is Firefox 78 I've set the version to 78 Branch.

I haven't tested this, but I suspect adding FLAC to extraMimeEntries should fix this.

(In reply to Martin Giger [:freaktechnik] from comment #0)

HTTP “Content-Type” of “application/x-unknown-content-type” is not supported. Load of media resource moz-extension://b920bd4a-df19-4d21-b433-3297132eec05/pop.flac failed. index.html
Cannot play media. No decoders for requested formats: application/x-unknown-content-type index.html

However, if the FLAC file is opened in a separate tab, it can be played just fine (see link at the bottom of index.html).

I haven't tested, but I guess that opening in the browser triggers the content sniffer (at netwerk/streamconv/converters/nsUnknownDecoder.cpp?), which ends up identifying the correct MIME type.

(In reply to Rob Wu [:robwu] from comment #2)

(In reply to Martin Giger [:freaktechnik] from comment #0)

HTTP “Content-Type” of “application/x-unknown-content-type” is not supported. Load of media resource moz-extension://b920bd4a-df19-4d21-b433-3297132eec05/pop.flac failed. index.html
Cannot play media. No decoders for requested formats: application/x-unknown-content-type index.html

However, if the FLAC file is opened in a separate tab, it can be played just fine (see link at the bottom of index.html).

I haven't tested, but I guess that opening in the browser triggers the content sniffer (at netwerk/streamconv/converters/nsUnknownDecoder.cpp?), which ends up identifying the correct MIME type.

Do we intentionally not run this for moz-extension files?

Also, if the unknown decoder can figure out a mimetype, why do we not have a mimetype on the moz-extension channel?

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

(In reply to :Gijs (he/him) from comment #3)

(In reply to Rob Wu [:robwu] from comment #2)

I haven't tested, but I guess that opening in the browser triggers the content sniffer, which ends up identifying the correct MIME type.

I initially thought of the content sniffer because the content sniffer for media elements (<video> and <audio>) is less permissive than the set of content sniffers that apply when a resource is loaded in the browser. This doesn't seem to be related to this issue, because the reported MIME type "application/x-unknown-content-type" should be handled similarly for media and generic sniffing.

Do we intentionally not run this for moz-extension files?

The report states "if the FLAC file is opened in a separate tab, it can be played just fine". So I guess that this is not only about moz-extension:.

I also asked the reporter on Matrix to check a few things, and here are the remarkable results:

• Refreshing the moz-extension://../index.html page doesn't make any difference.
• Opening the pop.flac file in a new tab, then refreshing index.html causes the file to load successfully.

The last point is very surprising. It is as if loading the media in the content process initializes some state. Martin (the reporter) is checking some more scenarios and will post a new comment with more information.

I managed to intermittently reproduce the lack of playback, but with a different error. I have filed a new bug at bug 1654105

As Rob said above, I've been trying to further narrow down some details here. To do so I've created a slightly modified test extension. This one creates a new audio element every time you press the button and appends it to the body of the page.

It also had the ability to play a remote flac file, which always worked fine, however it did not affect behavior at all, so I've removed that again.

We found out that the extension flac file was playable in the extension page after being played in the separate tab if the player tried to re-load the file (so essentially clicking play in the extension page after playing the flac in its own tab, or reloading the extension page in the old version).

However, if I close the tab with the raw file and reload the extension page (to purge all the audio elements in its DOM), at some point I'd see these log messages (when running the flatpak with flatpak run --env=MOZ_LOG=MediaDemuxer:5,MediaDecoder:5 org.mozilla.firefox)

[Child 125: MediaDecoderStateMachine #2]: D/MediaDecoder MediaDecoderStateMachine[0x7f518183e000] Decoder=7f518166ac00 MediaDecoderStateMachine::Reset
[Child 125: MediaDecoderStateMachine #2]: D/MediaDecoder VideoSink=0x7f5181682580 [Shutdown]
[Child 125: MediaPDecoder #2]: D/MediaDemuxer FlacTrackDemuxer[0x7f5183e4e120] Reset()
[Child 125: MediaPDecoder #2]: D/MediaDemuxer FlacTrackDemuxer[0x7f5183e4e120] Reset()
[Child 125: MediaDecoderStateMachine #2]: D/MediaDecoder MediaDecoderStateMachine[0x7f518183e000] Decoder=7f518166ac00 Shutting down state machine task queue

If I tried to load the extension FLAC in a player in an extension page (so pressing play) again after these logs, it would go back to the NotAllowedError again.