> can i ask, how do you use the "abort" event handler?
> and "error" event handler"
>
In jQuery 1.x, we don't even use onsuccess, onerror and onabort. Reason
being onreadystatechange is the only cross-browser means to handle
XMLHttpRequest when you have to support old IEs (and we try and avoid
hav
>> Key here is to make it possible for author to know what's going on and onabort seems quite confusing can i ask, how do you use the "abort" event handler?and "error" event handler" in case of user abort, it is not good to reconnect or show warningbut in case of error, it is good
Hello> On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren wrote:>> Currently the XMLHttpRequest Standard special cases the condition>> where the end user terminates the request. Given that there's less and>> less likely to be UI for that kind of feature, does it still make>> sens
I agree with Glenn that these user cancellations would be better notified
as errors rather than aborts. Key here is to make it possible for authors
to know what's going on and onabort seems quite confusing.
Side note: IE not cancelling requests is a real pain, we have to abort
manually on unload i
On Mon, Feb 25, 2013 at 3:37 AM, Anne van Kesteren wrote:
> Sure, for links (i.e. navigation)... For XMLHttpRequest (fetching)
> however those rarely change as that would make applications very
> confusing to the user. At least, when I still worked at Opera at some
> point the progress bars for f
On Mon, Feb 25, 2013 at 9:22 AM, Julian Aubourg wrote:
> AFAIK, clicking the stop button of the navigator or clicking on a link in
> the page will abort outbound requests. That's exactly the kind of aborts
> authors want to differentiate from network errors. I assume those buttons
> are UI feature
AFAIK, clicking the stop button of the navigator or clicking on a link in
the page will abort outbound requests. That's exactly the kind of aborts
authors want to differentiate from network errors. I assume those buttons
are UI features that permit request cancellation for users? Or am I
completly
On Mon, Feb 25, 2013 at 8:20 AM, Julian Aubourg wrote:
> I have the same questions as Jungkee. What is it you want to remove exactly?
> Why do you think the distinction between an user-initiated abort and a
> network error is irrelevant? If I am to believe jQuery's bug tracker, our
> users want an
I have the same questions as Jungkee. What is it you want to remove
exactly? Why do you think the distinction between an user-initiated abort
and a network error is irrelevant? If I am to believe jQuery's bug tracker,
our users want and need the distinction.
On 25 February 2013 07:49, Jungkee Song
> From: Timmy Willison [mailto:timmywill...@gmail.com]
> Sent: Monday, February 25, 2013 2:55 AM
>
> > On Feb 24, 2013, at 11:18 AM, Glenn Maynard wrote:
> > > On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren
> > > wrote:
> > > Currently the XMLHttpRequest Standard special cases the conditio
On Feb 24, 2013, at 11:18 AM, Glenn Maynard wrote:
> On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren wrote:
>> Currently the XMLHttpRequest Standard special cases the condition
>> where the end user terminates the request. Given that there's less and
>> less likely to be UI for that kind of
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren wrote:
> Currently the XMLHttpRequest Standard special cases the condition
> where the end user terminates the request. Given that there's less and
> less likely to be UI for that kind of feature, does it still make
> sense to expose this distinc
12 matches
Mail list logo