W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [XHR2] final progress events

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Thu, 17 Mar 2011 21:09:09 +0200
Message-ID: <4D825C55.7070509@helsinki.fi>
To: Glenn Maynard <glenn@zewt.org>
CC: public-webapps@w3.org, Jonas Sicking <jonas@sicking.cc>
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)

Received on Thursday, 17 March 2011 19:09:44 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC