[whatwg] Restarting the media element resource fetch algorithm after "load" event

[Ian Hickson]

On Thu, 8 Oct 2009, Robert O'Callahan wrote:
>
> http://www.whatwg.org/specs/web-apps/current-work/#loading-the-media-resource
> 
> In the resource fetch algorithm, after we reach the NETWORK_LOADED state 
> in step 3 which indicates that all the data we need to play the resource 
> is now available locally, we end the resource fetch algorithm. However, 
> in Gecko we have a media cache which might discard blocks of media data 
> after we've reached the NETWORK_LOADED state (to make room for data for 
> other loading resources). This means we might have to start fetching the 
> resource again later. The spec does not seem to allow for this. Do we 
> need to change our behavior, or does the spec need to change to 
> accommodate our behavior? I'd prefer not to change our behavior since I 
> think to follow the spec we'd need to pin the entire resource 
> permanently in the cache after we reached NETWORK_LOADED, which could be 
> highly suboptimal in some situations.

Step 2 says "While the user agent might still need network access to 
obtain parts of the media resource, the user agent must remain on this 
step". It even has an example of a UA that discards video data.


> Another issue is that it's not completely clear to me what is meant by 
> "While the user agent might still need network access to obtain parts of 
> the media resource" What if there is data in the resource that we don't 
> need in order to play through normally, but which might be needed in 
> some special situations (e.g., enabling subtitles, or seeking using an 
> index), and we optimize to not load that data unless/until we need it? 
> In that case would we never reach NETWORK_LOADED?

Correct.


> In general NETWORK_LOADED and the "load" event seem rather useless and 
> dangerous IMHO. If you're playing a resource that doesn't fit in your 
> cache then you'll certainly never reach NETWORK_LOADED, and since 
> authors can't know the cache size they can never rely on "load" firing. 
> And if you allow the cache discarding behavior I described above, 
> authors can't rely on data actually being present locally even after 
> "load" has fired. I suspect many authors will make invalid assumptions 
> about "load" being sure to fire and about what "load" means if it does 
> fire. Does anyone have any use cases that "load" actually solves?

I'm happy to remove 'load'. It's mostly a holdover from the first cut at 
this API, where this wasn't thought through in much detail.


On Fri, 9 Oct 2009, Robert O'Callahan wrote:
> 
> Me too. I'm game if you are!
> 
> So I propose:
> 1) Remove the NETWORK_LOADED state and "load" and "loadend" events from
> media elements. The resource fetch algorithm simply never transitions from
> step 2 to step 3.

Done.

NOTE: I've changed NETWORK_NO_SOURCE's value from 4 to 3!


On Fri, 9 Oct 2009, Simon Pieters wrote:
> 
> 'loadend' also fires after 'abort' and (when using the src attribute) 
> 'error'. Should that stay as is, or also be removed?

On Fri, 9 Oct 2009, Philip Jägenstedt wrote:
> 
> Since we're going to contradict the progress events spec anyway, I would 
> suggest dropping all 'loadend' events. They're just not very useful.

I've left it in the other cases, since, well, Progress Events says to. But 
I'd be happy to drop loadend in all cases (including other Progress Events 
cases) if that makes sense.


On Tue, 13 Oct 2009, Andrew Scherkus wrote:
>
> We're also baffled at what to report in our progress events because the 
> numbers are seemingly useless in our context.  Sometimes we'll cache the 
> end of the file to grab some useful metadata, but we don't want to fire 
> a progress event saying we've loaded the last bit of the file...

On Wed, 14 Oct 2009, Robert O'Callahan wrote:
> 
> We have the same issue, unsurprisingly. Currently our progress events 
> are not very useful because we report the download position (although we 
> do suppress progress events while we read metadata from the end of the 
> file). According to the spec, however, progress events should report the 
> *amount* of data downloaded, not the position within the resource. 
> That's a bit more useful, although it's still unclear what to do when 
> data is discarded from the cache and then re-downloaded.

Ok, I've switched them back to regular Event events, though using the same 
event names.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'