[whatwg] HTMLMediaElement.preload and stalled event
silviapfeiffer1 at gmail.com
Thu Jul 22 22:11:39 PDT 2010
To me, stalled implies that the UA is trying to receive stuff, but is
being stalled. So, my understanding is that the resource fetch
algorithm in  should include the word "unexpectedly" - that would
fix it. Then, if no data has been received for more than 3 seconds,
the "stalled" event would be fired - and again in another 3 seconds
etc, until we time out with an error. But if the UA isn't expecting
data, such as in a suspended state for preload:none or
preload:metadata, the @readyState is HAVE_NONE or HAVE_METADATA, and
the events fired are emptied or loadedmetadata respectively - and
An alternative interpretation would be that stalled implies that
playback is stalled. But even then, it doesn't really make sense,
since we are not trying to play, but are still in pause state.
On Fri, Jul 23, 2010 at 1:25 PM, Chris Pearce <chris at pearce.org.nz> wrote:
> I am implementing HTMLMediaElement.preload in Firefox, and I have a
> Should we be periodically firing a "stalled" event at the media element
> while we've suspended download of a preload:none or preload:metadata media?
> In step 2 of the resource fetch algorithm , the spec says "If at any
> point the user agent has received no data for more than about three seconds,
> then queue a task to fire a simple event named stalled at the element." But
> the description of the "stalled" event  says "The user agent is trying to
> fetch media data, but data is unexpectedly not forthcoming." The later
> description seems to imply that we only send "stalled" events when we
> unexpectedly stop receiving data, but the resource fetch algorithm indicates
> we should send "stalled" events if we stop receiving data for any reason,
> even if we suspend the download, and thus expect to not receive data.
> If we should send the stalled events, we should update the description of
> the stalled event at  to reflect that.
> Chris Pearce.
More information about the whatwg