/ node-XMLHttpRequest Publicforked from rase-/node-XMLHttpRequest
Fixed abort/error/loadend event firing, statusCode on error, exceptions #6
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.
I had to look at this because my application was hanging indefinitely using this particular XHR lib -- I had a domain name spelled wrong, and neither the error() nor load() events were firing, so my Promise was never resolving nor rejecting.
This fix addresses that problem by correcting the firing order (and ability to fire) of load, loadend, abort and error events. It also fixes the mis-fire of abort in the current driverdan 1.8 (original repo) version of this code that re-presented itself when I fixed abort firing.
A few smaller fixes were made while debugging this; in particular, status is supposed to be zero when the error handler fires, but was set to 503. I left it at 503 for the extra-process request stuff since I didn't have time to give that enough thought.
Also, I made exceptions into instanceof Error so that stack traces work (already done in driverdan code), and I threw all the event firing once readyState=4 on the NodeJS event loop. I left the earlier events alone since putting everything on the event loop was causing firing order issues; no readyState transistions were firing until the readyState was 4. I expect this change will let multiple load/error/abort handlers which await other (non-xhr) events to interoperate better with no correctness impact.