fix(xhr): reject navigation-canceled requests as ECONNABORTED - #11094

Summary

Firefox 152 stopped firing error and abort for XHRs canceled by a document navigation, emitting only readystatechange and loadend (bugzilla 1505389, and Mozilla upstreamed a conformance test for it in wpt#59603). Since onerror/onabort are what reject and null the request handle, and that null is the only thing making onloadend bail, onloadend became the only handler that runs. settle() then resolved the canceled request through its !response.status branch, so callers received a successful response carrying status: 0 and an empty body.

This rejects that case in the XHR adapter instead, with ECONNABORTED / Request aborted. That is the same error Firefox 151 produced for the identical cancellation, so an application sees no change in outcome across the Firefox update. Mozilla confirmed the old behavior on the bug ("only the onabort callback is called instead of onerror") and the patch that changed it is titled "Fires readystatechange and loadend intead of abort".

lib/core/settle.js is deliberately untouched, because it is shared with the fetch adapter where an opaque no-cors response legitimately carries status 0.

Patch-level behavior change, not a breaking API change. Browser requests whose response reaches loadend with status 0 previously resolved with an empty body and now reject with ECONNABORTED / Request aborted. Two consequences worth stating explicitly:

• Reads over file:, which some environments report as status 0 on success, still resolve. The exemption looks at the scheme of the request URL, at the scheme of the page origin for relative URLs (which inherit it), and at responseURL where implemented.
• The rejection is not suppressed by validateStatus. It never consulted it for status 0 anyway, since !response.status short-circuits ahead of it, and onerror/onabort reject unconditionally for the same reason: there is no response to validate.

This is XHR-only. The fetch and Node HTTP adapters do not have the equivalent failure mode, and are unchanged.

Linked issue

Closes #11093

Changes

• lib/adapters/xhr.js: reject with ECONNABORTED when onloadend is reached with status 0, excluding file: reads.
• tests/browser/requests.browser.test.js: a rejection test for the non-file: case, and a resolve test for a relative file: read, placed next to the existing file-protocol test.
• tests/unit/adapters/xhr.test.js: unit tests that drive the real adapter in Node with stubbed globals, covering the relative file: read without responseURL raised in review, plus reject and resolve controls for the other exemption sources.
• PRE_RELEASE_CHANGELOG.md: entry under Bug Fixes.

Checklist

• Tests added or updated (or N/A with reason)
• Docs/types updated if public API changed (index.d.ts and index.d.cts) - N/A, no public API change. The existing ECONNABORTED description ("timed out ... or aborted by the browser or its plugin") already covers this case.
• No breaking changes (or called out explicitly above)

Validation

Run against this branch, on top of v1.x at 5097193 (1.19.0):

npm run lint                            exit 0
npm run build                           exit 0
npm run test:vitest:browser:headless    591 passed (chromium, firefox, webkit)

npm run test:vitest:unit has 2 failures in tests/unit/adapters/fetch.test.js, both of which reproduce identically on a pristine checkout of v1.x, so they are unrelated to this change.

Each new assertion was mutation-tested: removing the guard fails the rejection tests, and dropping any of the three file: exemption sources fails a corresponding test.

Note that Playwright's bundled Firefox is 151, which predates the behavior being fixed, so the regression cannot be reproduced through the browser runner. The tests use the existing MockXMLHttpRequest, whose finish() already fires only onloadend, which is exactly the Firefox 152 shape. The browser harness also cannot serve a page over file:, so the page-origin exemption is covered by the unit tests instead, which stub the globals before importing axios so the real adapter runs with a file: origin.

🏄 Investigated and written with AI assistance, reviewed before opening.

Summary by cubic

Reject navigation-canceled XHRs with status 0 as ECONNABORTED to prevent empty successes on Firefox 152+. Successful file: reads still resolve, including relative paths inferred from the page’s file: origin or via responseURL.

• Description

  • XHR adapter now rejects on loadend with status 0 unless it’s a file: read (checks normalized request URL, page origin for relative URLs, and responseURL).
  • Added normalizeURLForProtocolCheck to match WHATWG URL preprocessing; used by XHR protocol checks and imported by buildFullPath.
  • Leaves lib/core/settle.js unchanged to avoid impacting fetch’s opaque no-cors responses.
  • Rejection occurs before validateStatus, since no response was received.

• Testing and Impact

  • Browser tests: reject non-file: status 0; resolve absolute/relative file: reads, including via responseURL.
  • Unit tests: cover page-origin inference, URL normalization (leading spaces/C0 controls), and that validateStatus is not called.
  • Docs: update /docs/ browser/XHR section to note status 0 on loadend rejects as ECONNABORTED, except successful file: reads; clarify validateStatus is not applied without a response.
  • Semantic version: Patch (XHR-only bug fix; Node and fetch adapters unchanged).

^{Written for commit 27b9d97. Summary will update on new commits.}