W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: XMLHttpRequest progress events

From: Gorm Haug Eriksen <gormer@opera.com>
Date: Mon, 24 Apr 2006 17:25:38 +0200
To: "Boris Zbarsky" <bzbarsky@mit.edu>, "Web APIs WG (public)" <public-webapi@w3.org>
Message-ID: <op.s8iqg0o7m2jbu9@pt-osx.oslo.opera.com>

Hi Boris,

On Sun, 23 Apr 2006 20:51:03 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> At the moment, Gecko allows adding a single "onprogress"  
> DOMEventListener that's notified of download progress.
> We would like to make two changes to the progress event setup:
> 1)  Allow adding progress event listeners via addEventListener, not just  
> via
>      setting the onprogress property.  The event name would be  
> "progress".

This sounds like a good idea.

Btw, I found two strange behaviours while looking at it now. It seems like  
the onprogress event is one cycle before responseText.length. Also,  
strange things seems to happen if the Content-Length header is missing.

Opera will probably wait until this group has made an recommendation  
because the same behaviour is possible to implement without the onprogress  
event (by checking the Content-Length header and watching the length of  
responseText as it progress).

> 2)  Allow adding upload progress event listeners via addEventListener.   
> The
>      event name would be "uploadprogress".
> The timeline for this would be to make the change in development builds  
> in the next several weeks and to ship it hopefully early next year.
> Does this seem acceptable?  If not, are there counter-proposals?

I would wait until all vendors get a chance to review a proposal in  
public. The people that need this behaviour are capable of implementing it  
today using server side scripting. Is this acceptable?


- Gorm Eriksen
Received on Monday, 24 April 2006 15:25:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC