Re: XMLHttpRequest progress events

Maciej Stachowiak wrote:

> Between this and the always-null input attribute, it seems re-using 
> LSProgress might not be that useful, although using the same names for 
> the applicable attributes may still be a good idea.

OK, sounds reasonable.

> 1) You'll get at least one progress event for the full size of the 
> resource. That way you can always use this event alone to make a 
> progress bar, although the granularity may be very poor.

This raises the question of what "full size of the resource" is for something 
like gzip-encoded HTTP...  I'm not sure I can usefully define something here 
that makes sense in general.

Note that if indicating load done is all you want you can use readyState changes 
to do it (once readyState changes, put the progress bar at 100%).

> 2) If you ask for responseText, you are guaranteed to see at least as 
> much decoded data as the last progress event reported.

Again, it's not clear how this interacts with HTTP content-encoding -- the 
decoded text may be shorter than the encoded one, in theory.

That said, it does make sense to require that the responseText be the decoded 
version of at least as much data as was reported via progress events.

One issue here is what responseText is _during_ the progress event.  In Gecko, 
and for HTTP, the progress event is fired before the OnDataAvailable 
notification that actually passes data from the networking library to 
XMLHttpRequest.  So as Gorm Haug Eriksen pointed out earlier, the progress 
events always seem a step ahead of the responseText.  For other protocols, for 
example FTP, the ordering in Gecko seems to be the other way around.  I just 
talked to one of the networking guys, and he's not sure what changing the HTTP 
behavior would entail.  At the very least there are security implications, since 
unfortunately the secure state indicator for web pages uses some of these 
events.  :(

> 3) Might want to define when progress events occur relative to 
> readystatechange events - I'm not sure what this should even be.

Hmm....  Part of the problem here is that as far as I can tell the readyState 
values don't really express well what happens during upload.  "progress" events 
would only fire when readyState is 3.  "uploadprogress" events would presumably 
happen before readyState changes to 2 (since by "2" we have at least the headers 
from the server response), right?

-Boris

Received on Monday, 24 April 2006 17:45:44 UTC