Safari 14 audio test returns empty values for typical formats

[beshur]

I am working on a project and noticed that in Safari 14 (technological preview on Mac Catalina) Modernizr.audio returns this:

{ogg: "", mp3: "", opus: "", wav: "", m4a: "maybe"}

However, it plays MP3 just fine on other sites, most online test suites show it can play MP3 and M4A.

[Markel]

Confirmed using Browserstack, and it is definitely something about Safari 14 and not the device. Now, why does it happen? No idea... Nothing in the changelog seems to say anything about audio... It may be anti-fingerprinting technology? Or simply just a bug from Safari 14?

[Markel]

Maybe have to do something with the bunch of things related to audio of release 113??, but honestly I don't even know if that is the last version. I'm not very familiar with Safari (don't even own a iOS device)

[beshur]

Safari 14 is the next stable version (currently in beta), coming out with the next Mac OS version later this year.

While something changed in Safari, some other site for testing HTML5 features do a different check and yield positive results for mp3.

[beshur]

Apple just released Safari 14
https://www.macrumors.com/2020/09/16/apple-releases-safari-14-for-mac/

[Markel]

Yeah, we should get to it. But sorry, university is slowing me 😅😅

[beshur]

That's going to break a lot of sites, more people inbound, I can assure you.

In the meantime I found that codecs is missing from canPlayType in Safari.

[Markel]

In the meantime I found that codecs is missing from canPlayType in Safari.

@beshur What do you mean by that?

[beshur]

I meant that Modernizr in its check for audio types support creates a DOM media element and checks for the canPlayType method:

Modernizr/feature-detects/audio.js

Line 48 in 3b0eb2b

Modernizr.addTest('audio.ogg', elem.canPlayType('audio/ogg; codecs="vorbis"').replace(/^no$/, ''));

And Safari 14 does not understand the codecs part of it, which is not part of the spec. Chrome still understands though.

I have submitted a comment on the related issue in Webkit bugzilla, and someone has promptly made a patch for mp3, and I am not sure what's going to happen to it next.

[Markel]

I mean we cannot delete the codecs part as that wouldn't make sense as the container and the codecs are two different things (something even more apparent in the video test, which is also affected by this bug). Honestly I don't really know what can we do in this case...