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

RESOLVED INVALID

Status

()

Core
Audio/Video
--
major
RESOLVED INVALID
9 years ago
6 years ago

People

(Reporter: Craig, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
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

9 years ago
see bug 494379 and bug 481040
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio

Comment 2

9 years ago
(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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.