Re: Firing media events early for throttled downloads

On Wed, Apr 29, 2009 at 5:23 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 2 Apr 2009, Robert O'Callahan wrote:
> > Suppose a page waits for the "canplaythrough" or "load" events to fire
> > on an "autobuffer" media element before it starts playing the media.
> > Then suppose that a user-agent has a media data cache that's smaller
> > than the size of the media resource, so after loading some amount of the
> > data the user-agent decides to pause the download because the cache is
> > full. Unfortunately, the page will never start playing the media.
> >
> > Authors can work around this by starting playback on receiving the
> > "stalled" event. (I'm assuming the the user agent is able to free up
> > cache space for played media data, so it will be able to resume the
> > download and eventually play the entire resource.) But that event could
> > fire in other situations, say due to temporary network stalls, when the
> > page would not need to start playback. It's also a trap for authors; in
> > testing they might never notice that the "stalled" handler is needed.
> >
> > Should the spec allow the user-agent to set the media element ready
> > state to HAVE_ENOUGH_DATA, and to fire the "load" event, if it pauses
> > the download due to local resource constraints that may persist
> > indefinitely?
>
> The 'suspend' event, already specified, is intended for this case.
>

OK, that's good, but it's still going to be a trap for authors to listen for
"load" or  "canplaythrough" and forget to listen for "suspend" because that
never fires in their test setup.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]