430 bytes, text/html
26.85 KB, image/png
25.20 KB, image/png
25.23 KB, image/png
762 bytes, text/plain
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20100928 Firefox/4.0b7pre Build Identifier: 4.0b7pre When invalid <audio> src URLs are used the audio player disappears. Reproducible: Sometimes Steps to Reproduce: 1.Navigate to http://happyworm.com/mftest/indexduff.htm Actual Results: The player appears on the screen briefly before disappearing. Expected Results: The player remains on the screen somehow indicating that the src URL is invalid.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Component: General → Video/Audio
Ever confirmed: true
QA Contact: general → video.audio
Did Firefox 3.6 behave the same way? Would this be likely to be an issue in the videocontrols code or in the backend?
(In reply to comment #1) > Did Firefox 3.6 behave the same way? > > Would this be likely to be an issue in the videocontrols code or in the > backend? This regressed in this range: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-09-02+09&enddate=2010-09-03+04 That would be a regression from my load algorithm changes and video controls changes checked in for bug 485288 in that range. This bug is fixed by my patches in bug 505158, a combination of backend and controls changes.
Depends on: 505158
Fixed by landing of bug 505158.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
blocking2.0: ? → final+
I ran into this same issue with today's nightly (Nightly 11.0a1 2011-12-05 x86_64 linux) so it must not have been entirely fixed. The original example is 404, so I'll attach a brief page demonstrating the issue. Basically, I want <audio src="invalid-url" controls> to leave something on the screen. The 'controls' attribute means the user is relying on us to provide the ui for this audio clip, and just disappearing isn't doing that. Ideally we'd show an 'X' and/or an error message within the layout box of the normal audio controls.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Created attachment 579546 [details] Quick HTML example demonstrating current behaviour I get slightly different behaviour based on whether 'invalid.oga' exists or not. Without invalid.oga, the audio controls appear, but instantly fade out. If I 'touch invalid.oga' I get controls, which fade out when I click the play icon. In this case, when it fades the controls, I get a residual hashed zero-height box. This may be a Linux-specific artefact; it only appears when the window is focussed, so it may be a border drawn by the window manager? If 'invalid.oga' is an Ogg file with unsupported codecs, it usually behaves like no file at all, but every once in a while it behaves like an empty file.
Sigh, of course the fix for this just landed today. Will verify and close tomorrow.
Testcase URL: data:text/html,<audio src="invalid-url" controls style="border: solid red 2px;">
I am confused at a lot of things. Firstly that I was told that FF will only play .ogg ? Secondly what is wrong with using this code to play music: <embed src="music/alice.mp3" width="200" height="28" autostart="false"> </embed>Alice's Restaurant<br /> Works a treat, where: <audio controls="controls" height="50px" width="100px"> <source src="song.mp3" type="audio/mpeg" /> <source src="song.ogg" type="audio/ogg" /> <embed height="50px" width="100px" src="song.mp3" /> </audio> As advised by W3 schools, doesn't. (FF11)
I'm going to jump on this train a bit late -- bug still present in 17.0a1 (2012-08-22). I found it trying to create html5 audio elements (just messing about to learn how the new stuff works). Example: https://mirror.explodie.org/audio.html It works beautifully in chrome and IE9. I've tested it on both stable ff (14.0.1, Ubuntu 12.04 32bit) and nightly (win7, 32bit), and it fails the same way on both. If you don't click the page: What I was trying was to see if browsers would auto-fall-back to supported codecs in <audio>. There's a source (first one in the element) with an opus file, and another with an mp3 file. The audio controls appear for well under a second and then disappear. Occasionally (it seems like if I hit f5 fast enough!) the controls will appear, but when you hit play nothing happens. (This also means it isn't falling back to the mp3 file linked in the element. Urg.)
Okay so I've done more testing and it seems that Firefox will do opus in my example, but identifying it as opus is predicated on the mimetype from the server being correct (audio/ogg, and not application/octet-stream). Separate bug, filing now.
(In reply to Jacob Taylor from comment #13) > identifying it as opus is predicated on the mimetype from the > server being correct (audio/ogg, and not application/octet-stream). Separate > bug, filing now. If you do, please mark it as depending on bug 567077, which adds sniffers for ogg->application/ogg, but nothing specific for opus.
(In reply to Ralph Giles (:rillian) from comment #14) > > If you do, please mark it as depending on bug 567077, which adds sniffers > for ogg->application/ogg, but nothing specific for opus. Thanks, submitted and marked as a dependency.
Created attachment 754194 [details] hidden audio tag doesn't reappear when given new stream I can verify as of Firefox 21, this issue still persists and is present on more than Mac OSX, it also happens on Windows 7. (but I guess I can't change that on this ticket) I see it in a project I wrote hosted at https://radios.asmcbain.net/nectarine/ which the first time you load that web app will try to load an AAC stream if your browser supports it. The code listed it as "audio/mp4" so Firefox says it supports it and thus it gets put in the list of choices, but it actually comes back as "audio/aacp" which Firefox then rejects. (The mismatch is my bug, not Firefoxes of course, but the disappearing problem it causes is Firefox's.) I've attached a new test-case which shows that even if you set the source to a new valid stream that Firefox does support, the player does not reappear. I used to be able to make the player reappear by setting the display style dynamically to "block" (or something) then back to "". This no longer works as of Firefox 20 or so. The only solution I can see at the moment is to completely remove the element from the page/DOM then create and add a new one with the new stream when this happens. Nowhere near ideal :(
When you set the src to an invalid stream, there is an error that appears on the console, but unfortunately there doesn't seem to be a way to do something sensible, so the player just disappears. [14:16:12.294] HTTP "Content-Type" of "audio/aacp" is not supported. Load of media resource http://bbcmedia.ic.llnwd.net/stream/bbcmedia_intl_lc_radio2_p?s=1378401358&e=1378415758&h=59599c8e09f0be6562937fff73a4bffd failed. @ chrome://unitedradio/content/radio/radio-window.xul In my case, I'm trying to create a generic player, but I have no way of knowing what content is going to make it to the player. It's quite frustrating that it simply disappears with bad content...
To be clear, I can get the error via the error message, but I can't do anything to make the player reappear. I've gone through the XUL and nothing is there that I can mess with.
As https://bugzilla.mozilla.org/show_bug.cgi?id=1116516 (bug #1116516) shows even Nightly 37 is not able to report error if source is invalid. The bar does not appears/disappears, but, unlike Internet Explorer, error message like "Invalid source" or "Can not load source data" does not appear within the bar, and users just in loss on whether the server is busy/slow/overloaded at the time and it is worth to wait, or there is nothing to wait at all. Can we have an assignee to implement showing of error message within the HMTL5 audio player bar, just like in Internet Explorer?
We're not going to get to this for a while, we're overwhelmed by higher priority issues at the moment.
Component: Audio/Video → Audio/Video: Playback
Mass closing do to inactivity. Feel free to re-open if still needed.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 4 months ago
Resolution: --- → INACTIVE
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
You need to log in before you can comment on or make changes to this bug.