- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Thu, 17 Mar 2011 21:11:58 +0200
- To: public-webapps@w3.org
- CC: Glenn Maynard <glenn@zewt.org>, Jonas Sicking <jonas@sicking.cc>
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.
Received on Thursday, 17 March 2011 19:12:27 UTC