22058 2013-05-16 09:42:00 +0000 "error" event should fire before final readystatechange event 2013-05-16 11:40:28 +0000 1 1 1 Unclassified WebAppsWG XHR unspecified PC Linux RESOLVED WONTFIX P2 normal --- 1 hsteen annevk mike public-webapps public-webapps-bugzilla oldest_to_newest 87751 0 hsteen 2013-05-16 09:42:00 +0000 #request-error part of spec: Step 6: Fire an event named readystatechange. . . Step 9: Fire a progress event named event. // this fires the actual 'error' event This seems to be an order of events that isn't really user-friendly. Given a typical XHR-using script has logic like this: if readystatechange fires with readyState === 4 report "success", handle response data if error event fires report failure this typical XHR user would end up running the "success" code first, then the "failure" code. This seems less than ideal.. Is there any reason we can't move the "fire error" step to before the "fire readystatechange" step? 87753 1 hsteen 2013-05-16 09:51:02 +0000 (I guess the real answer is "we want to push users to not rely on readystatechange but use load/error events instead" :-p) 87757 2 annevk 2013-05-16 11:40:28 +0000 Either fully use readystatechange or use the other set of events. If you start mixing, you're on your own.