UrlLib StatusText for fetch + XMLHttpRequest.statusText (closes #193)

[bkaradzic-microsoft]

Closes #193.

Summary

Now that BabylonJS/UrlLib#30 is merged, UrlRequest::StatusText() (the wire reason phrase where available, else a canonical code→text fallback table) is available upstream:

• Fetch: drop the private status-code→text table in Fetch.cpp and read request.StatusText() into Response.statusText.
• XMLHttpRequest: expose statusText (previously absent) — now free from the same UrlLib API.
• Adds fetch + XMLHttpRequest statusText unit tests (OK / Not Found).

The UrlLib pin is bumped to BabylonJS/UrlLib 74985214 (the UrlLib#30 merge commit).

Verified locally: Fetch and XMLHttpRequest polyfill libraries build clean against the bumped UrlLib pin (Win32 Chakra). Unit tests (incl. the new statusText tests) run in CI.

Notes

• statusText is consumed purely to decorate error messages (nothing branches on it), so the concrete win is e.g. 404 Not Found instead of 404 undefined. The code→text fallback table in UrlLib is the right shape for how the value is used (real browsers return "" over HTTP/2).
• Apple/Android currently get their reason phrase from UrlLib's fallback table (their native HTTP stacks don't surface the raw phrase); wiring Android's getResponseMessage() is a possible follow-up.

[Copilot]

Pull request overview

This PR aligns the fetch and XMLHttpRequest polyfills with upstream UrlLib’s newly exposed HTTP reason phrase API (UrlRequest::StatusText()), removing the local status-code→text mapping and adding test coverage for statusText.

Changes:

• Fetch: remove the local StatusText mapping table and populate Response.statusText from UrlRequest::StatusText().
• XMLHttpRequest: add a read-only statusText accessor wired to UrlRequest::StatusText().
• Tests: add/extend unit tests asserting statusText for 200 OK and 404 Not Found, and bump the UrlLib pin to the merge commit that provides StatusText().

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
Tests/UnitTests/Scripts/tests.ts	Adds/extends unit tests for fetch + XMLHttpRequest statusText on 200/404 responses.
Polyfills/XMLHttpRequest/Source/XMLHttpRequest.h	Declares GetStatusText and exposes statusText on the JS wrapper.
Polyfills/XMLHttpRequest/Source/XMLHttpRequest.cpp	Implements statusText getter using UrlRequest::StatusText().
Polyfills/Fetch/Source/Fetch.cpp	Drops the local status-text table and sets Response.statusText from UrlLib.
CMakeLists.txt	Updates the UrlLib GIT_TAG pin to include UrlRequest::StatusText().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[matthargett]

This lands the statusText hop nicely — single source of truth in UrlLib with the wire phrase preferred and the shared fallback table keeping platforms consistent (and avoiding the localizedStringForStatusCode: localization trap on Apple). 👍

Heads-up that this slots into a larger chain we just wrote up in #196: BabylonJS/UrlLib#31 (open) adds normalized transport-error detail to UrlLib (ErrorString() / ErrorSymbol() / ErrorCode()), which unblocks fixing the "fetch: network request failed" constant-string rejection in Fetch.cpp the same way this PR consumed StatusText() — i.e. a pin bump plus TypeError + cause/code in the error path.

Question on logistics so we don't collide: would you like us to submit PRs for consuming UrlLib#31 (fetch/XHR error shape) and the related wiring from #196 (unhandled-rejection delivery, init.signal), or would you prefer to fold any of that into this draft / handle it in your own follow-up PRs? Happy either way — we mainly want the order of operations to be deliberate since this PR, the UrlLib pin, and the error-path change all touch the same files.

[matthargett]

These cover the happy path well — would you be open to also porting a handful of the bun/node (undici) and WPT tests for this functional area, to validate the runtime behavior cross-platform in CI? The highest-value ones for statusText/error semantics specifically:

• undici test/fetch/client-fetch.js-style assertions that a transport failure rejects with a TypeError carrying a cause (today it's a plain Error with a constant message — see fetch/XHR transport failures and unhandled rejections lose all diagnostic fidelity before reaching the embedding app #196 / Expose normalized transport-error detail (ErrorString/ErrorSymbol/ErrorCode) UrlLib#31 for the plumbing that makes the detail available);
• WPT fetch/api/basic/http-response-code semantics (4xx/5xx resolve, only transport failures reject) — partially covered by the 404 test here, worth pinning for 500s;
• a statusText case against an HTTP/1.1 origin with a non-canonical reason phrase, which would document the platform split (curl/Windows report the wire phrase, Apple/Android the table value);
• response.statusText === "" tolerance over HTTP/2 per spec (the fallback table makes BN report canonical text where browsers/bun/node report "" — fine, but worth a deliberate test so the deviation is documented).

If you'd rather keep this PR scoped to the statusText wiring, we're happy to do the test porting in a follow-up PR instead — whichever you prefer.