W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [XHR2] load events on XMHttpRequestUpload

From: Darin Fisher <darin@chromium.org>
Date: Thu, 23 Jun 2011 13:10:37 -0700
Message-ID: <BANLkTi=_RK44gGnp9eEpx3FLm-4pH0Sgk8=AUEvfWaWRb3oo9Q@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org, "Tony Chang (Google)" <tony@chromium.org>
On Tue, Jun 21, 2011 at 12:30 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 6/21/11 3:01 PM, Darin Fisher wrote:
>> Isn't there already a signal to tell you when response headers are
>> available?
> Yes; I believe the readystate changes at this point and onreadystatechange
> is fired.
>  Isn't it a bit redundant for the upload complete notification to be tied
>> to the
>> same signal?
> Yes, sure.  But that the point when the browser knows the upload is
> complete....

It really depends on how you define complete.  I think it is useful to know
all of the data has been sent.  That seems useful to applications.  An
might wish to switch from a progress meter for upload percentage to a static
notification indicating that the application is now simply waiting for a
Chrome for instance does exactly this in its status bar for HTML form
Why shouldn't web apps be able to present the same kind of detailed upload
progress UI?

>  To support the use case of showing a progress meter, it seems helpful to
>> know when the browser has finished writing bytes on the wire.
> If you're willing to restart the meter from 0 in some cases, perhaps.

Yeah :-)

> > It also seems like it would be useful
>> for there to be a "resend" event indicating that the upload will be
>> resent.  Otherwise, one
>> has to guess this.
> Yep.
> -Boris

So, anyways... I think I like how Chrome is behaving.  I haven't checked to
if this is a property of WebKit or Chromium's networking layer.  I suspect
it is
a WebKit detail.  Anyways, I think it would be useful to update the spec to
support this behavior.  It seems useful :-)

Received on Thursday, 23 June 2011 20:11:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:20 UTC