[whatwg] Form submission progress display by UA (incl. file upload)

[timeless]

On 1/24/08, Mikko Rantalainen <mikko.rantalainen at peda.net> wrote:
> Consider a form with a file input. User selects a huge file and hits
> submit. Most UAs do not display nothing but an animated throbber until
> the full submit is done and the download progress bar only starts to do
> anything after the full submit part is already done. An another example
> could be a long blog article that is being sent over an GPRS mobile
> connection (with common speeds around 9kbps).
>
> I think that WF2 section 5.6
> (http://www.whatwg.org/specs/web-forms/current-work/#methodAndEnctypes)
> should be modified to say something along the lines
>
> "User agents with interactive user interfaces should inform the user
> about the progress of the data submission. For example, an UA with a
> graphical user interface could display a visual progress bar which would
> be updated once every second; the bar would be initially displayed as
> empty and would fill over time as the encoded form data set is
> transmitted. For transmissions that take more than a few seconds UA
> might in addition display estimated time before done."

My embedded device battery managers will complain about anything that
happens more than once every 30s (they do).

> Rationale: Upload progress monitoring is becoming more important every
> day as browsers are often used for content authoring, the digital
> content gets bigger and common user connections are highly asymmetric
> (e.g. 24mbps downstream, 1mbps upstream in case of ADSL2+). The delay
> expected by the user for sending a 100MB file could be close to
> downloading a 100MB which is not the reality. An user in a hurry would
> hit stop button and retry again after waiting for some time without
> knowing that upload is in progress.

I think a slightly more beneficial thing would be for the file picker
posting system to be able to tell the user how big the file is and how
long submitting a form should take at some transfer time. I'm not sure
if anything like this is exposed.

http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl
lists a fileSize property. I think it'd be nice if gmail could tell me
that "this file will take an hour to upload". I also wonder if it'd be
a good idea to support getting chunks of a file, because if I had a
4gb file, using DOMFile().getAsBinary() would probably crash my
browser. I'd kinda like for gmail to be able to do partial uploads....
In order for this to work, there should be DOMString hash() which has
an optional argument for a hash algorithm ("md5sum", a const for
md5sum, or maybe an object { processBlock:function(data) {},
getHash:function() }. Otherwise a user could try feeding sequential
blocks from different files.

Currently, file uploading is a kinda syncish process.

As to your actual concerns, gmail already deals w/ uploading in the
background fairly gracefully. And in IE6, there is a progress meter
during the upload (Gecko doesn't show proper progress, but I believe
that's a bug).

I'm not sure I see what value is added by somehow mandating this
"feature". Evolving browsers will probably add this feature anyway
through competition.