- From: <bugzilla@jessica.w3.org>
- Date: Thu, 16 May 2013 09:42:00 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22058
Bug ID: 22058
Summary: "error" event should fire before final
readystatechange event
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: XHR
Assignee: annevk@annevk.nl
Reporter: hallvord@opera.com
QA Contact: public-webapps-bugzilla@w3.org
CC: mike@w3.org, public-webapps@w3.org
#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?
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 16 May 2013 09:42:02 UTC