[whatwg] File Upload Progress Event (Upload Progress)

[Ian Hickson]

On Sun, 19 Sep 2010, Shiv Kumar wrote:
>
> I'd like to propose that UAs should surface an bytes transferred event 
> when a form is being submitted. With so many large files being uploaded 
> using browsers today and every website that allows this having had to 
> implement their own upload progress indicator I think the Html 5 spec 
> should support this very common need.

I disagree with the premise that the page has to implement its own 
progress indicator. The browser should do that.


On Sun, 19 Sep 2010, Shiv Kumar wrote:
> 
> I'm uploading a large file using an iframe. So yes, the iframe will be 
> submitted, but the rest of the page is intact. I'm still left without 
> having the ability to know how long the upload is going to take and how 
> it is progressing. So while the form is submitting, today we go through 
> quite a bit of hackry to show our users progress. Having the event and 
> information allows us to provide a consistent (across browsers) 
> interface which is extremely important (as you can imagine) and does not 
> require the server side to support this. Currently, we monitor the bytes 
> received on the server side (and no web server gives you easy access to 
> this information) and make that available (per session) to the client 
> UA.

It seems like the better solution is just to have the browser display an 
obvious progress bar as it uploads the file.


> I agree! I'd love to see browsers provide their own information in a 
> more noticeable/useful fashion, but I still think surfacing the event 
> and information allows web developers the option to display such 
> information in a consistent manner (across browsers) without having to 
> resort to handling the entire submission process using XMLHttpRequest.

Actually handling the submission process using XHR is only a few lines of 
code; probably about as many lines of code as it would take to display a 
progress bar if we exposed progress events for the form submission itself. 
So it's not clear to me that we would gain much by doing that.


On Mon, 20 Sep 2010, Shiv Kumar wrote:
> 
> If I have:
> 
> <input type="file" id="somefilefield" onuploadprogress="displayProgress()"/>
>
> for example is a lot more approachable (and easy to modify existing 
> code) than having to submit the form using the FileAPI or FormData along 
> with XMLHttpRequest. And yes you can create a Javascript library method 
> that submits the form for you by passing it the id of the form element, 
> but you'll still need to implement that event handler to be able to 
> customize it the way you need. So rather than go full circle, let's just 
> have any event :)
>
> The onuploadprogress event could either be on the <form> or on the 
> <input>. Having it on the input gives you the ability to show progress 
> for multiple files, however, browsers may choose the upload one file at 
> a time.

The problem is that the browser is allowed to blow away the page as soon 
as the server starts responding, which it can do before the entire upload 
has been received, as far as I can tell. So the feature could be somewhat 
unreliable. I think it's better to give authors direct control over the 
entire process using the XMLHttpRequest form submission feature.


On Tue, 21 Sep 2010, Roger Hågensen wrote:
> 
> Well! There is nothing preventing the specs from providing a minimum UI 
> guideline that should be followed by UAs.

We could, but in general we try to not give requirements for things that 
aren't required for interoperability. Giving UI requirements would not 
really do any good since browsers would just ignore them (they'd have no 
incentive to obey them if they disagreed with them, and if they agree with 
them, putting them in the spec wouldn't give them any more incentive than 
they have already).


On Mon, 20 Sep 2010, Shiv Kumar wrote:
> 
> In order to show a upload progress using the new FileAPI/FormData I'd 
> have to write the event handler so I can control the way I want things 
> displayed. I'd have to write the same event handler code to show upload 
> progress if I were to hook into my proposed onuploadprogress event too.
> 
> The difference is that I didn't have to mess with the FileAPI/FormData 
> stuff to do it. Frankly, if we have one (FileAPI/FormData that has a 
> progress event) I don't see why we can't have the other. The difference 
> is I'm subscribing to the event declaratively (more Html like). Browser 
> vendors would already have the ability to do this once they implement 
> the FileAPI.

It's not clear to me that the benefit is that great. We're talking about 
half a dozen lines of code here.


> I don't expect anything frankly, I only hope :). But I'm not hoping for 
> priority of implementations, but rather that it be added to the spec. 

Adding it to the spec doesn't do anything if it doesn't get added to 
implementations also. Given that UAs haven't made upload feedback a 
priority, why would they make events for upload a priority? It's more or 
less the same difficulty in practice.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'