User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20090807 Shiretoko/3.5.2 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20090807 Shiretoko/3.5.2 Some Ogg Vorbis files fail when embedded in an <audio> tag, even though the same files will play normally in the embedded player if you download the file and access it directly as a file on the filesystem (i.e. save the file to /tmp, then type "/tmp/(name of file)" into the URL bar, and the file plays.) On files that fail, the embedded player and controls appear for a moment, then becomes a blank grey box. I'd previously seen this on Ogg Vorbis files exported by Audacity, which subsequently worked if instead encoded by oggenc. However, the example linked above was also encoded with oggenc and fails in the same way. My report of "All Operating Systems" is slightly optimistic, but I have confirmed it on both Linux x86 and x86_64 nd Mac OSX ("Leopard" if it matters). (On the Linux x86_64 box, the audio player disappears entirely rather than being replaced by a blank grey box...) Reproducible: Always Steps to Reproduce: 1.Create Ogg Vorbis audio file with as-yet-unknown properties that Firefox doesn't like (example file on linked page) 2.Reference said file in a page in an <audio> tag 3.Load page in firefox 3.5.x (<= 3.5.2, at least) 3.Scream "ARGH! The LAST file worked, why doesn't this one!?!?", bang head on table repeatedly, and question one's nerdness (optional step) Actual Results: Audio player displays "throbber" for a moment, then is replaced by a blank grey box (or disappears entirely) Expected Results: Audio player should stubbornly refuse to disappear and instead wait patiently for me to press the "play" button, at which point it should play the audio.
Okay, I feel stupid now - Still a bug, but probably NOT related to playing Ogg Vorbis data. Finally had time to look at the details again and found that NONE of the group files I had in <audio> tags was working now (same symptom - begins loading then gives me a blank grey box). Problem: 404-error. I had the wrong file path. Once the path was corrected, the example file (and the others) worked correctly. Possibly the <audio> player is trying to interpret the 404-error page as ogg vorbis audio and dying as a result? Change "Expected Results:" to say: Audio player should 'trap' errors accessing the file and indicate somehow what the problem is ("<URL> does not exist" message where the "Throbber" appears above the controls, perhaps?) rather than going blank.
We don't do a very good job of indicating errors have occurred when loading video/audio media right now. There's a bug to fix that, so I'll mark this as a duplicate of that one.