- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 16 Aug 2013 17:48:00 -0700
- To: Hallvord Steen <hsteen@mozilla.com>
- Cc: Jungkee Song <jungkees@gmail.com>, public-webapps <public-webapps@w3.org>, Anne van Kesteren <annevk@annevk.nl>, Glenn Maynard <glenn@zewt.org>, Julian Aubourg <j@ubourg.net>, hallvors@yahoo.com
On Fri, Aug 16, 2013 at 10:40 AM, Hallvord Steen <hsteen@mozilla.com> wrote: > > 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 ;-) I come to the opposite conclusion. If the user stops a request then we should assume that the user wanted to. We shouldn't assume that users are erratic and don't know what they are doing. Ideally we should separate all three types of errors. Though it's already possible for a page to know if it called abort since that can be handled through page-specific logic. So we need to be able to tell network errors from user aborts. > (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). Gecko used to have UI for stopping XHR traffic, though this was more by accident than an intentional decision. I believe this has since been fixed. So based on the knowledge that browsers generally don't have UI for aborting XHRs, I would draw the conclusion that if the user did cause an abort, that that was *not* accidental but rather intentional. / Jonas
Received on Saturday, 17 August 2013 00:48:58 UTC