Member Avatar for misterrmac

I while back I added a little countdown timer for an action on our website which also plays a ticking and "ding" sound. I didn't have too much trouble getting it to work across all browsers...or at least I thought.

I received a complaint from a visitor that they were getting a message in Safari (on windows) that there was an unknown MIME type on the page. Testing it on my install of Safari, it works fine. I quickly found what different MIME types are needed depending on the browser and players installed on the system in question. I can easily code a routine to use the correct mime type in JS or PHP. However, because playback depends on what the visitor is using and has installed, they can still get an error. I believe, if the browser can't load or play the sound (or any MIME type) it should fail gracefully (nothing at all or a message on the page , without some bulky browser error message window the user needs to close in order to continue.

Which brings me to my question: is there a way to prevent a browser from throwing up some error message if it does not know how to load the MIME type in question?

Thanks in advance
Loren

  • 2 Contributors
  • 2 Replies
  • 185 Views
  • 23 Hours Discussion Span
  • Latest Post Latest Post by misterrmac

Dani AI

Generated

— that modal “unknown MIME type” comes from the browser handing the file to a plugin or external handler, which is outside the page’s JavaScript control. Once the browser does that handoff, the native dialog cannot be suppressed from the page. was on the right track: keeping playback inside a controlled player (HTML5/JS or a JS library) prevents the browser from invoking external plugins and makes graceful failure possible.

Practical options that avoid native popups:

  • Use HTML5 audio feature-detection (create an Audio object and check canPlayType) and only attach a src when supported; listen for error and present an inline fallback.
  • Load audio via fetch/XHR + Web Audio API (decodeAudioData) — decode errors are caught in JS and will not trigger plugin UI.
  • For older browsers, use a well-tested player library that provides in-page fallbacks rather than raw <embed>/<object> tags.

Example: feature-detect + graceful handler

var a = document.createElement('audio');
if (a && typeof a.canPlayType === 'function' &&
    (a.canPlayType('audio/mpeg') || a.canPlayType('audio/ogg'))) {
  a.preload = 'auto';
  a.src = '/sounds/tick.mp3';
  a.addEventListener('error', function(){ /* show inline fallback or ignore */ });
}

Server-side checks remain important: ensure correct Content-Type headers so modern browsers recognise formats (example for Apache):

# .htaccess
AddType audio/mpeg .mp3
AddType audio/ogg  .ogg
AddType audio/wav  .wav

Testing checklist: verify the response Content-Type in the browser Network panel, confirm HTML5 <audio> playback on a small test page, and only use direct file embeds when a native download/view behavior is acceptable. Avoid mislabeling MIME types to silence dialogs — that breaks proper playback and can create other problems.

Recommended Answers

All 2 Replies

Member Avatar for samarudge

Hey,
Unfortunately when just loading a plain sound file there is no way of managing the errors (Its a browser error)
The only thing I would sugest is using some sort of Flash framework and refferencing it through JS. Or if you are feeling adventurous you could play about with <HTML5>

Member Avatar for misterrmac

Preloading is setting up the player to be ready to play so the situation would be the same as if I were to just let it play. I can remember seeing on some sites a message on the page where a player plug-in would go, not a pop-up error message. Only I can't remember where or reproduce it.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.