- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 14 Aug 2009 09:16:44 +0000 (UTC)
- To: Simon Pieters <simonp@opera.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
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