Re: 'progress' events for media elements

On Fri, 7 Aug 2009, Simon Pieters wrote:
>
> The spec says to fire 'progress' events every 350ms while downloading 
> media data. If all media data is in cache, no 'progress' events will be 
> fired. However, the 'load' event is not fired until the resource 
> selection algorithm has finished, and the resource selection algorithm 
> includes decoding data, so it is not predictable how long it will take 
> until the 'load' event is fired.
> 
> This makes it impossible to test that 'progress' events are fired at 
> all, since a browser could just claim that they have all media data 
> cached and are just spending time on decoding the video as part of the 
> resource selection algorithm.

So reset your cache and then do it. Or load a file you know isn't cached 
(e.g. give it a unique name each time). You can know when the server 
finished serving the file pretty easily; until then, the UA can't pretend 
it's caching. This doesn't seem hard to test, unless I'm missing 
something.


> I would suggest that the spec require that one 'progress' event is fired 
> when all data is loaded, but not waiting for anything to be decoded. 
> This will make 'progress' testable and also make progress bars more 
> accurate.

Done.

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

Received on Friday, 14 August 2009 09:17:20 UTC