On 03/17/2011 09:09 PM, Olli Pettay wrote:
On 03/17/2011 08:40 PM, Glenn Maynard wrote:
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.
Note, *if* we decide to change progress event behavior in XHR,
it should be probably changed also in File API which has the same
progress event handling as XHR.
(AFAIK, gecko implements in both cases what the specs say, and
webkit does something else)
Actually, when I last time tested XHR on webkit,
Safari/nightly-webkit and Chrome-v11 seemed to have different behavior.
Perhaps because of different network layer.
IIRC, nightly-webkit dispatched progress events very often.
