- From: Hallvord Steen <hsteen@mozilla.com>
- Date: Fri, 16 Aug 2013 10:40:17 -0700 (PDT)
- To: Jungkee Song <jungkees@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>, Anne van Kesteren <annevk@annevk.nl>, glenn@zewt.org, Julian Aubourg <j@ubourg.net>, hallvors@yahoo.com
> -> If the request cancellation is trigger by the end user
> This is an abort error.
> Note: The request cancellations by the end user include clicking
> on a stop button in browser chrome, hitting escape, page navigation, etc.
>
> WDYT?
I think the real reason for the disagreement is that the feature lacks a real, solid use case - except, perhaps, if a script wanted to do alert('Hi, please stop clicking the "Stop" button while we\'re processing your order') or something. There simply isn't much a script can sensibly do in response to a user interruption (certainly when one isn't quite sure if it is the user interrupting or not..)
However, what one might want to do is to re-schedule some request and try again later. In this respect, I think a user cancellation is much closer to a network error than an abort() call. If the network fails, you can assume it's somewhat erratic and it makes sense to try in a minute. If the user clicks stop, I guess you can also assume that the user is somewhat erratic and it makes sense to try again later ;-) (99% of users won't really understand that they interrupted something, or what they interrupted, especially since I believe browsers do not tend to have "stop" UI for XHR traffic).
By that logic I think having it classified as an 'error' event is better, but IMO this is a minor detail and not really worth our time..
-Hallvord
Received on Friday, 16 August 2013 17:40:44 UTC