According to specification, the behavior for XMLHttpRequest.status should be as follows: The status attribute must return the result of running these steps: * If the state is UNSENT or OPENED, return 0 and terminate these steps. * If the error flag is set, return 0 and terminate these steps. * Return the HTTP status code. Currently, WebKit does: * Return 0 if the state in UNSET * Throw an INVALID_STATE_ERR if state is OPENED * Return HTTP status code (even if error flag is set) Firefox and Opera both follow the spec exactly. What IE9 does: * If the state is UNSENT or OPENED, throw an exception * If the error flag is set, throw an exception * Return HTTP status code.
Created attachment 173335 [details] Results with different browsers
I attached the results of LayoutTests/http/tests/xmlhttprequest/status-after-abort.html with all major browsers.
Created attachment 173342 [details] Patch
Comment on attachment 173342 [details] Patch Attachment 173342 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14788251 New failing tests: fast/js/dfg-custom-getter-throw.html fast/js/dfg-custom-getter-throw-inlined.html
Created attachment 173364 [details] Patch Update the following tests since they relied on XMLHTTPRequest.status to throw: fast/js/dfg-custom-getter-throw.html fast/js/dfg-custom-getter-throw-inlined.html
This changes many behaviors at once. To pick one, both IE and WebKit raise an exception in OPENED state. Why shouldn't the spec be changed to match the vast majority of browsers here? Generally, speaking, Firefox, Opera and a spec combined don't have enough weight for us to change unless there is an additional good reason to.
Comment on attachment 173364 [details] Patch Clearing review flag on patches from before 2014. If this patch is still relevant, please reset the r? flag.
This bug is handled by bug 45994 last patch. Once bug 45994 is closed, this bug should probably be closed as well.
*** This bug has been marked as a duplicate of bug 45994 ***