[XHR2] final progress events

>From https://bugzilla.mozilla.org/show_bug.cgi?id=637002:

>> If you leave this as invalid, would it at least be possible (or even necessary)
>> to fire the progress event one last time (e.g. right when finished sending all
>> bytes without waiting for the servers response) and to set evt.loaded ==
>> evt.total ?
> That could violate XMLHttpRequest v2 spec. progress events shouldn't fire
> more often than every 50ms.

I think this should be considered.  Currently, a final onprogress
event may not be fired.  For example, this means progress indicators
can sit at 98% at the end of a transfer, since progress events
typically look like this in Firefox:

[12:20:14.172] "359887, 4194446" (loaded, total)
[12:20:14.206] "1899983, 4194446"
[12:20:14.242] "3767759, 4194446"

with no onprogress(4194446, 4194446) event ever sent.  The final event
is delayed due to the 50ms timer, and then never sent because the
transfer completes first.

For download progress you can work around this by watching onload and
treating that as a progress(total, total) event, but that shouldn't be
required.

For upload progress you may not be able to work around this with
onload, depending on when upload.onload is supposed to fire.  If it
fires when the server headers are received, that's much too late.  By
then, you may have already shown a progress indicator at 98% for
several seconds (if the server takes some time to process and respond
to the request).  See the "load events on XMHttpRequestUpload" thread.

I suggest requiring that a progress event be fired when loaded ==
total, regardless of the 50ms interval timer.  WebKit appears to
already do this in all cases: xhr.onprogress is always sent before
readyState is changed to DONE, and xhr.upload.onprogress is always
sent before onload.

-- 
Glenn Maynard

Received on Thursday, 17 March 2011 18:40:56 UTC