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: Wed, 12 Apr 2017 10:16:26 +0300
To: whatwg@lists.whatwg.org
Message-ID: <ddac01d6-82a7-1511-5a9d-dea9310b47fc@peda.net>
Anne van Kesteren (2017-04-11 16:05 Europe/Helsinki):
> On Tue, Apr 11, 2017 at 2:44 PM, Mikko Rantalainen
> <mikko.rantalainen@peda.net> wrote:
>> Would it be possible to add "progress", "load", etc. events to normal
>> form elements, too? Basically, I would like to do
>>
>>   form.addEventListener('progress', function (e) {...})
>>
>> and if the end user hits the Submit button, my progress listener would
>> get called with ProgressEvent with lengthComputable, loaded and total
>> attributes.
>> [...]
>>
>> If listening for "progress" were allowed, I could implement my own form
>> submission UI and still use regular forms that would work even without
>> JavaScript.
> 
> It would leak new information cross-origin and due to redirects that
> would be hard to distinguish from same-origin. You'd also have to
> submit into some kind of <iframe> as otherwise you end up navigating
> anyway.

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.

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.

I didn't understand the point about redirects making
same-origin/cross-origin harder to distinguish.

-- 
Mikko
Received on Wednesday, 12 April 2017 07:17:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 12 April 2017 07:17:04 UTC