Re: [XHR2] final progress events

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