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

[Mikko Rantalainen]

timeless wrote:
> On 1/24/08, Mikko Rantalainen <mikko.rantalainen at peda.net> wrote:
>> 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).

It's wise to always trying to minimize the battery usage in a battery
operated device. However, if the device is already using wireless or
wired communication for transmitting the data set it cannot just do
"nothing". Notice, also, that I wasn't suggesting that the above text is
a "MUST" but instead just "SHOULD". Perhaps it could be even "recommended".

>> [an user uploading a huge file over slow uplink] 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.

How can the "file picker posting system" know something like actual
bandwidth beforehand? Perhaps the user is using a mobile device that is
currently on WLAN connection (say 54mbps) and the user starts sending
the file. If the file picker has told the user that sending takes
approximately 5 minutes for the selected file, how is the user supposed
to know the actual sending time after he starts moving and the
connection drops to 3G mobile network (around 0.5mbps) or GPRS or GSM
data mobile network (around 0.001mbps). I cannot imagine anything but a
progress bar displaying the current rate (or transfer rate for the
previous 30 seconds if that's how often the progress can be updated
because the battery must be conserved).

> 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.

I agree that something like that would be nice to have for some cases.
However, I do not think that such behavior would make upload progress
monitoring unneeded. The current "fix" for this problem is to connect
the receiving server with HttpXmlRequest() and ask the server how much
data the server has received. Then this result can be displayed somehow
to the user.

> 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 don't think that IE has a working upload progress meter. I have always
experienced IE just to simply slowly increase the progress meter until
the page is done; it's advancing even if I disconnect the network cable
during the progress... (just tried IE6 and IE7)

> 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.

If it will probably be added in the future anyway shouldn't the spec
recommend doing so sooner? I'm not saying that every UA MUST do so but
they should (unless they have a good reason not to).

-- 
Mikko

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080125/15c27ff4/attachment-0001.pgp>