W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2017

Re: [whatwg] Adding progress event for native <form>?

From: Mikko Rantalainen <mikko.rantalainen@peda.net>
Date: Thu, 13 Apr 2017 12:22:50 +0300
To: whatwg@lists.whatwg.org
Message-ID: <caa62c32-7ad9-fff0-9fd7-3f006a32d3f3@peda.net>
Anne van Kesteren (2017-04-12 10:25 Europe/Helsinki):
> On Wed, Apr 12, 2017 at 9:16 AM, Mikko Rantalainen
> <mikko.rantalainen@peda.net> wrote:
>> The default use case would not need to use frames. The expected use case
>> would be to display custom UI for submission progress (e.g. nice
>> progress bar and ETA with custom algorithm). It would be just fine to
>> "lose" this custom UI once the submission is complete and next page or
>> resource has been displayed.
> 
> Every now and then there's some talk about navigation transition
> animations. That might be all you need here. (Sorry, no pointer at
> hand.)

I don't agree that transition animations are enough.

Consider a mobile user uploading a form with 50 MB file over 2G EDGE
connection (about 250 Kbps in practice). Such form submission will take
around 25-30 minutes. End user will not be happy with native user agent
progress display (for example, Google Chrome will display only a small
status text in bottom left corner saying 'Uploading (3%)...').
Navigation transition cannot obviously hide the 25 minute delay required
for the upload.

I'd expect a good upload UI to look more like the displays used in
http://beta.speedtest.net/ during the network connection testing. User
agents have had 20+ years to improve on such UI without success so I'd
like to have JS API to have a possibility to implement the missing UI by
myself.

Currently the only way to do this is to add JS code that attaches to the
form, prevents normal form submission, collects all form data including
file uploads and then uses XHR to submit the data while listening for
'progress' events. That's pretty much work to do just to show client
side progress bar and that may still not work correctly if server
responds to POST request with HTTP 303 because XHR cannot read original
response headers nor response body in case of redirects. In case of HTTP
303 JavaScript code would need to read the Location header and set
document.location to that value instead of getting headers and content
after the redirect.

Another possibility is to forget about HTML forms and non-JavaScript
fallback and always go with XHR specific implementation.


>> About the information leak: in case of cross-origin the user agent could
>> emit just one progress event with lengthComputable=false. However, I
>> have throuble figuring out a possible attack vendor even in case full
>> progress events were published cross-origin.
> 
> The problem is learning information about the destination server and
> being able to do better timing attacks.

OK. I think it would be fine to not publish details via progress events
as described above (lengthComputable=false) in case cross-origin traffic
would be needed.

-- 
Mikko
Received on Thursday, 13 April 2017 09:23:30 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 April 2017 09:23:31 UTC