600806 - If I give an invalid <audio> src the audio player appears and disappears or doesn't appear at all.

Status: REOPENED

Description

[Mark Boas]

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.

Comment 1

[David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-8 (if account gets disabled due to email bounces, ask a bugzilla admin to reenable it)]

Did Firefox 3.6 behave the same way?

Would this be likely to be an issue in the videocontrols code or in the backend?

Comment 2

[Chris Pearce (:cpearce)]

(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.

Comment 3

[Chris Pearce (:cpearce)]

Fixed by landing of bug 505158.

Comment 4

[Ralph Giles (:rillian) | needinfo me]

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.

Comment 5

[Ralph Giles (:rillian) | needinfo me]

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.

Comment 6

[Ralph Giles (:rillian) | needinfo me]

Created attachment 579547 [details]
audio element with controls

Comment 7

[Ralph Giles (:rillian) | needinfo me]

Created attachment 579548 [details]
audio element a second later

Comment 8

[Ralph Giles (:rillian) | needinfo me]

Created attachment 579549 [details]
faded audio element with residual border

Comment 9

[Ralph Giles (:rillian) | needinfo me]

Sigh, of course the fix for this just landed today. Will verify and close tomorrow.

Comment 10

[Chris Pearce (:cpearce)]

Testcase URL: data:text/html,<audio src="invalid-url" controls style="border: solid red 2px;">

Comment 11

[Colin]

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)

Comment 12

[Jacob Taylor]

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.)

Comment 13

[Jacob Taylor]

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.

Comment 14

[Ralph Giles (:rillian) | needinfo me]

(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.

Comment 15

[Jacob Taylor]

(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.

Comment 16

[Art McBain]

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 :(

Comment 17

[Art McBain]

I should also note, unlike either test-case, this problem also occurs (like in my little web app I linked) if you set the stream dynamically in JavaScript via the src property. It doesn't have to be set as the src attribute to cause the problem.

In my web app if this occurs you can go to the preferences, change to a good stream, save them, then reload the page. However that's annoying as well, and I imagine applications that don't offer that kind of freedom are rather stuck.

Comment 18

[Mike Kaply [:mkaply]]

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...

Comment 19

[Mike Kaply [:mkaply]]

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.

Comment 20

[User Dderss]

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?

Comment 21

[Chris Pearce (:cpearce)]

We're not going to get to this for a while, we're overwhelmed by higher priority issues at the moment.

Comment 23

[Nils Ohlmeier [:drno]]

Mass closing do to inactivity.
Feel free to re-open if still needed.