- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 2 Nov 2011 15:56:50 -0700
- To: Eric U <ericu@google.com>
- Cc: Glenn Maynard <glenn@zewt.org>, Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Kyle Huey <me@kylehuey.com>, public-webapps@w3.org
On Wed, Nov 2, 2011 at 9:56 AM, Eric U <ericu@google.com> wrote: > On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard <glenn@zewt.org> wrote: >>> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking <jonas@sicking.cc> wrote: >>>> >>>> 1. Make "loadend" not fire in case a new load is started from >>>> onabort/onload/onerror. Thus "loadend" and "loadstart" isn't always >>>> paired up. Though there is always a "loadend" fired after every >>>> "loadstart". >>>> 2. Make FileReader/FileWriter/FileSaver not behave like XHR. This also >>>> >>>> leaves the problem unsolved for XHR. >>>> >>>> Are there other options I'm missing? >>> >>> Or do both, improving XHR as much as backwards-compatibility allows and >>> don't try to match other APIs to it exactly. I'd much prefer weirdness be >>> isolated to XHR than be perpetuated through every PE-based API. >> >> So what exactly are you proposing we do for XHR and for FileReader/FileWriter? >> >> I'm still not convinced that it's better for authors to require them >> to use setTimeout to start a new load as opposed to let them restart >> the new load from within an event and cancel all following events. I >> agree that this introduces some inconsistency, but it only does so >> when authors explicitly reuses a FileReader/XHR/FileWriter for >> multiple requests. >> >> And it only weakens the invariant, not removes it. So instead of >> >> * There's exactly one 'loadend' event for each 'loadstart' event. >> >> we'll have >> >> * There's always a 'loadend' event fired after each 'loadstart' event. >> However there might be other 'loadstart' events fired in between. > > I'm for this. It lets FileReader and FileWriter match XHR, avoids [in > the odd case] long strings of stacked-up loadend events, and users can > avoid all the issues either by creating a new FileReader or by > wrapping nested calls in timers if they care. I believe Jonas is in > favor of this as well. > > Can we put this one to bed? So the proposal here is to allow new loads to be started from within abort/error/load event handlers, and for "loadend" to *not* fire if a new load has already started by the time the abort/error/load event is done firing. And the goal is that XMLHttpRequest, FileReader and FileWriter all behave this way. Is this correct? If so, I agree that this sounds like a good solution. / Jonas
Received on Wednesday, 2 November 2011 22:57:59 UTC