Open Bug 1704115 Opened 29 days ago Updated 18 days ago

Firefox fails to play specific m4a (NS_ERROR_DOM_MEDIA_METADATA_ERR)


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

Firefox 89





(Reporter: liamrengland, Unassigned)



(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Actual user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0 (I'm using RFP)

Visit or in a new tab

Actual results:

Audio decoding fails with NS_ERROR_DOM_MEDIA_METADATA_ERR (0x806e0006)

Expected results:

Audio plays as expected

I think it's reproducible on all tiktok audios served with the m4a extension. More: or

These files are MPEG-4 audio, which should have the MIME type audio/mp4 per rfc4337. However, they're being served as audio/mpeg:

$ curl -IL ""
HTTP/1.1 200 OK
Server: nginx
Content-Type: audio/mpeg

which is the MIME type for MPEG-1 and MPEG-2 layer I, II or III (in other words, .mp3 files) per rfc3003.

Are there any examples of files being served like this in the context of a tiktok page? It's possible that the MIME type would be different in context and this problem only occurs when using these URLs directly.

Unfortunately, the simple solution of adding audio/mpeg to the MIME types accepted in MP4Decoder.cpp breaks regular mp3 files, so if we end up supporting this, it will be more involved.

Flags: needinfo?(liamrengland)

The audios are served with the same (wrong) MIME type when listening on tiktok's site, but tiktok's player (I think it's a version of this library) handles the mismatch correctly. You can test on any of the below URLs on tiktok's website (you can play the audio by pressing play on the album cover).

So, this is pretty low-priority, but a webcompat difference between Chrome and Firefox.

Flags: needinfo?(liamrengland)

*as in chrome can do it and firefox can't. The site works fine in both browsers.

Over the last 10 years, the expected behaviour changed drastically.

I was not really specified before 2014, but the behaviour we've been using for Firefox went from "only using the mimetype, refusing to play if (e.g.) application/octet-stream or no Content-Type header, or empty Content-Type header", (2011 and before) to "sniff, but only when served with no Content-Type header or application/octet-stream (2012 and after).

After long discussions it was specified to ignore the Content-Type header:, and this still is the behaviour to adopt today.

Firefox is not implementing the standard here, and we should sniff in all cases, ignoring the type (except if X-Content-Type-Options: nosniff is specified I assume).

Severity: -- → S3
Priority: -- → P3

(In reply to Paul Adenot (:padenot) from comment #5)

Firefox is not implementing the standard here, and we should sniff in all cases, ignoring the type (except if X-Content-Type-Options: nosniff is specified I assume).

Anne, fyi. The patch is up, but I'm pretty sure I need to adjust quite a few tests I wrote for this 10 years ago, and probably add some.

Flags: needinfo?(annevk)

video and audio elements should always sniff, even when nosniff is present, I think. It would surprise me if Chrome implemented something different.

Navigating directly to a video or audio resource is different and there nosniff might have to be respected, though we've also run into some issues there with Chrome not respecting it as much as we did.

So I would recommend testing both of those contexts separately and comparing with Chrome/Safari. Happy to help diagnose weird results and things that need clarification in the standard (I know the nosniff stuff for navigations still isn't where it needs to be).

Flags: needinfo?(annevk)
You need to log in before you can comment on or make changes to this bug.