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
having
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
On Mon, Feb 25, 2013 at 8:20 AM, Julian Aubourg j...@ubourg.net 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
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 9:22 AM, Julian Aubourg j...@ubourg.net 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
On Mon, Feb 25, 2013 at 3:37 AM, Anne van Kesteren ann...@annevk.nl 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
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
Hello On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl 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
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
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 distinction from a network error in the API? I
think we should merge them.
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl 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
On Feb 24, 2013, at 11:18 AM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
Currently the XMLHttpRequest Standard special cases the condition
where the end user terminates the request. Given that there's less and
less likely
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 gl...@zewt.org wrote:
On Sun, Feb 24, 2013 at 8:18 AM, Anne van Kesteren ann...@annevk.nl
wrote:
Currently the XMLHttpRequest Standard special
13 matches
Mail list logo
