This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7428 - Safari 4 preloads media and FF 3.5 doesn't in <audio> tag; perhaps HTML5 sections 4.8.10.5 4.8.10.8 are unclear or need a 'preloading' attribute added.
Summary: Safari 4 preloads media and FF 3.5 doesn't in <audio> tag; perhaps HTML5 sect...
Status: VERIFIED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NE, NoReply
Depends on:
Blocks:
 
Reported: 2009-08-26 01:31 UTC by Steven Rowat
Modified: 2010-10-04 13:58 UTC (History)
4 users (show)

See Also:

Attachments

Description Steven Rowat 2009-08-26 01:31:34 UTC 
User agents FF and Safari have opposite implementations of preloading of audio media using the same <audio> HTML, apparently due to insufficient clarity in HTML5 4.8.10.5 Autobuffer and 4.8.10.8 Autoplay requirements.

This causes a page with many audio controllers (such as a search results page) to load so slowly in Safari that it is unusable. 

Examination of the relevant sections in the HTML 5 Aug 25 draft proposal (reproduced below) show that there is no specific direction about preloading behavior. This should be fixed, because whether or not the page preloads media is a major determinant of page success/usability when there are multiple controllers.

To clarify: a page with one or two controllers will perform fine whether there is a preload or not, but a search results page (for example), or any page with many controllers, will only function well if the controllers do NOT preload. Preloading 25+ controllers can take minutes of spinning beach balls before control of the cursor is regained by the user. This is unacceptable and it should be within the power of the page author to specify that preloading is not to occur.

More specifically:

Firefox, encountering an <audio> and <source> tag with src media, does not preload if the autoplay and autobuffer are both absent. See mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=493860
 Bug 493860 -  Add a pref to disable automatic download of videos (ogg) even if autoplay/autobuffer is set  

See comment #5
"If autoplay and autobuffer are not specified on the element, Firefox will stop fetching data once enough has been downloaded to decode the first frame of the video or (for audio only) the audio metadata has loaded."

Safari, with the same configuration, does preload the media. 

Here are relevant sections I can find in the HTML5 Aug 25 draft:

"4.8.10.5 Loading the media resource

"The autobuffer  attribute is a boolean attribute. Its presence hints to the user agent that the author believes that the media element will likely be used, even though the element does not have an autoplay  attribute. (The attribute has no effect if used in conjunction with the autoplay attribute, though including both is not an error.) This attribute may be ignored altogether. The attribute must be ignored if the autoplay attribute is present."

4.8.10.8 Playing the media resource

"The autoplay  attribute is a boolean attribute. When present, the user agent (as described in the algorithm described herein) will automatically begin playback of the media resource as soon as it can do so without stopping"


The main thing I notice about these sections is that automatic preloading is not mentioned and so must be interpolated; apparently in opposite directions by the two user-agents.

I can see two possible solutions (the first probably easier):
  1. Specify as part of the spec that preloading is not to occur if both autoplay and autobuffer are absent (the FF behavior).
  2. Define a new boolean attribute, 'autoload', and attach that behavior to it: ie., if it's absent, no preload; if it's present, preload.

Perhaps it's possible to control these things via Javascript and/or the DOM as well, but I've managed to avoid going there for many years and I don't want to start now. :-) . Joking aside, I think this is a straightforward and important issue that should be available to anyone who writes HTML/CSS; ie, that there should be an HTML element attribute combination that unequivocally controls <audio> media preloading.

p.s.
It wouldn't surpise me to find that this is all the same for <video>, but I haven't tested it.
Comment 1 Robert O'Callahan (Mozilla) 2009-08-26 05:49:32 UTC 
Your 'autoload' suggestion means exactly the same thing as 'autobuffer' already does.

I think the spec already suggests to do what Firefox does. But the spec can't totally forbid preloading of any content the browser wants to, "autobuffer" or not, so Safari's behaviour should not be forbidden by the spec. You should take this up with the Safari developers, it's an implementation issue.
Comment 2 Steven Rowat 2009-08-26 17:45:35 UTC 
(In reply to comment #1)
> Your 'autoload' suggestion means exactly the same thing as 'autobuffer' already
> does.

You're partly right, but only because my suggestion wasn't clearly worded. Yes, we only need one of them. See below for why the current use of 'autobuffer' is inadequate.

> I think the spec already suggests to do what Firefox does.

I don't find anything in the wording to support this. 

"The autobuffer... hints to the user agent ....This attribute may be ignored altogether. The attribute must be ignored if the autoplay attribute is present." 

This says nothing about whether to preload or not. Is there something else somewhere else in the spec that I've missed? If not, I believe FF's developers made an educated guess about whether to preload. I believe more direction than that is required. 


> But the spec can't
> totally forbid preloading of any content the browser wants to, "autobuffer" or
> not, so Safari's behaviour should not be forbidden by the spec. 

I disagree strongly. Perhaps it can't 'totally forbid', but certainly it can 'highly recommend' in a case where there is a legitimate need, identified by the page author, that a certain page (with many controllers), not preload, if that would render the page unusable. 

My point, again, is that whether or not to preload media is legitimately a matter that depends on network conditions to some degree in any situation; but in the special situation where the page references to more data than can be comfortably handled by the network in the first few seconds (or minutes!) the best available solution appears to be to delay preloading. The page author is the person who is going to know this first and best, so they need a tool to indicate it.

Or, another option (more complicated, probably, but maybe preferable in some way) is that some elements/attributes can be defined so that the user-agent recognizes when it is loading multiple controllers and using more local CPU/memory than the local interface can handle (rendering cursor unusuable, for example) and decides on its own, based on this evidence, to stop the preloading for this page. Then the page author wouldn't need to be involved.

But it still seems easier to me just to restate the terms of use for 'autobuffer' and 'autoplay' so preloading can be prohibited by the author.

Steven Rowat
Comment 3 Robert O'Callahan (Mozilla) 2009-08-26 18:05:46 UTC 
The spec says:
> The autobuffer attribute provides a hint that the author expects that
> downloading the entire resource optimistically will be worth it, even in the
> absence of the autoplay  attribute. In the absence of either attribute, the
> user agent is likely to find that waiting until the user starts playback before
> downloading any further content leads to a more efficient use of the network
> resources.

The latter sentence is encouraging UAs to do what Firefox does.

> The page author is the person who is going to know this first and best,

No, the browser is in the best position to know what the user's network conditions are --- whether it's on a phone, or loading content over a very high-speed network or even the local file system, etc. User preferences are also relevant here. This does need to be ultimately controlled by the browser.
Comment 4 Steven Rowat 2009-08-27 00:39:52 UTC 
(In reply to comment #3)
> The spec says:
> > The autobuffer attribute provides a hint that the author expects that
> > downloading the entire resource optimistically will be worth it, even in the
> > absence of the autoplay  attribute. In the absence of either attribute, the
> > user agent is likely to find that waiting until the user starts playback before
> > downloading any further content leads to a more efficient use of the network
> > resources.
> 
> The latter sentence is encouraging UAs to do what Firefox does.

Right, I missed that. It's in a different section in the spec. Thank you. But apparently Safari developers either missed it also or choose to ignore it. Perhaps that idea could be repeated in the sections I quoted? 


 (In reply to comment #3)
>the browser is in the best position to know what the user's network
> conditions are --- whether it's on a phone, or loading content over a very
> high-speed network or even the local file system, etc. User preferences are
> also relevant here. This does need to be ultimately controlled by the browser.

Agreed that the browser is "in the best position to know" about the network conditions. But it's a machine after all and can't know what the conceptual framework of the page is; at least, not until a metadata language is widely implemented. Until then at least, the author is in the best position to know whether or not preloading of LARGE NUMBERS of media files should even be attempted. That is, unless the browser can intelligently decide that the network is too slow or too crowded or the CPU/RAM insufficient. But apparently Safari can't (or doesn't). 

I'm curious, and it seems relevant here: -- can Firefox? Are there situations where Firefox slows or stops preloading of media when there is danger of the page user losing the ability to interact because of lack of bandwidth/cpu?
Comment 5 Robert O'Callahan (Mozilla) 2009-08-27 02:00:11 UTC 
> Until then at least, the author is in the best position to know
> whether or not preloading of LARGE NUMBERS of media files should even be
> attempted. 

I agree, that's why we have autobuffer and why Firefox behaves as it does.

> Are there situations where Firefox slows or stops preloading of media when
> there is danger of the page user losing the ability to interact because of lack
> of bandwidth/cpu?

Yes. We have a limit on the size of data we preload, in a typical configuration it's 50MB. So if you have some large media files that have 'autobuffer', we will download them until their combined size reaches about 50MB, and then we'll pause the downloads until some of the data has been played or some of the elements are destroyed.

Downloads generally shouldn't stress the CPU. We should probably throttle bandwidth used by autobuffering, but we haven't gotten around to that yet.
Comment 6 Ian 'Hixie' Hickson 2009-09-18 01:02:45 UTC 
As far as I can tell, the proposal here is to include recommendations for what basically boil down to quality-of-implementation issues. It'd be like having a recommendation in the spec about how many MB of HTML a browser should be able to render fast. I don't think we can do that.
Comment 7 Maciej Stachowiak 2010-03-14 14:50:08 UTC 
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.