498540 - Audio and Video tags do not fallback to fallback content when codec is not supported

Status: RESOLVED INVALID

(Core :: Audio/Video, defect)

Description

[Craig]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1pre) Gecko/20090614 Ubuntu/9.10 (karmic) Shiretoko/3.5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1pre) Gecko/20090614 Ubuntu/9.10 (karmic) Shiretoko/3.5pre

According to https://developer.mozilla.org/En/Using_audio_and_video_in_Firefox :

"If the type attribute isn't specified, the media's type is retrieved from the server and checked to see if Gecko can handle it; if it can't be rendered, the next source is checked (and if there isn't one, the fallback content is displayed)."

Firefox seems to check each <source> element for codec support in order, as it should, but if no <source>'s will work, it simply displays a big box black box with a gray "X" in it where the player should be. By my reading of the above, it should display the fallback content instead of displaying this "X."

Reproducible: Always

Steps to Reproduce:
View this HTML in Firefox 3.5:
<audio controls="controls">
        <source src="http://podcastdownload.npr.org/anon.npr-podcasts/podcast/510286/103966586/npr_103966586.mp3" type="audio/mp3" />
        Not supported
</audio>
Actual Results:  
Big gray box with an "X" in it.

Expected Results:  
The words "Not supported"

I think this bug is "major" as it prevents web sites from implementing fallbacks to other player options. For example, Firefox 3.5 will not support mp3 audio, so I would like to fall back to a Flash mp3 player, but try using the audio tag first, so when Firefox does get that ability, or another browser does, the Flash will be seemlessly discarded.

On video sites, like Youtube, this could be especially important, as they could use the video tag to try to play h264, and fallback to a Flash player if that codec is not supported by the browser.

Comment 1

[Jo Hermans]

see bug 494379 and bug 481040

Comment 2

[Simon Pieters [:zcorpan]]

(In reply to comment #0)

> According to https://developer.mozilla.org/En/Using_audio_and_video_in_Firefox
> :

This is not the spec. The spec says:

"Content may be provided inside the video  element. User agents should not show this content to the user; it is intended for older Web browsers which do not support video, so that legacy video plugins can be tried, or to show text to the users of these older browser informing them of how to access the video contents."
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#video


> "If the type attribute isn't specified, the media's type is retrieved from the
> server and checked to see if Gecko can handle it; if it can't be rendered, the
> next source is checked (and if there isn't one, the fallback content is
> displayed)."

If there isn't one, the spec says you should wait until another <source> is inserted.
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm


> Firefox seems to check each <source> element for codec support in order, as it
> should, but if no <source>'s will work, it simply displays a big box black box
> with a gray "X" in it where the player should be.

This is correct per spec.

Comment 3

[Matthew Gregan [:kinetik]]

I've updated the documentation at developer.mozilla.org to reflect the spec.

If content authors consider the current fallback behaviour suboptimal, I recommend raising it on the HTML 5 mailing list for further discussion.