Wire blob: URL resolution through a UrlLib scheme resolver instead of per-polyfill branches

[bkaradzic-microsoft]

Summary

Resolve blob: URLs (from URL.createObjectURL) through a single scheme resolver so every consumer — fetch, XMLHttpRequest, <img>/<video> src, texture loaders, … — resolves them uniformly, instead of each polyfill special-casing the scheme.

Background

#207 adds URL.createObjectURL / URL.revokeObjectURL backed by an in-memory object-URL store in the URL polyfill. Because UrlLib::UrlRequest only understands app: / file: / http(s):, the fetch and XMLHttpRequest polyfills currently intercept the blob: scheme before handing the URL to UrlLib and serve the bytes from the store themselves.

As raised in review (discussion), that doesn't scale: blob: is special-cased in fetch and again in XMLHttpRequest, and image/video src and texture loaders would each need the same branch.

Proposed direction

1. Upstream (BabylonJS/UrlLib): add a registration hook for a custom scheme resolver — a callback that, given a blob: URL, yields the bytes, content-type, and a status (found → 200, revoked/unknown → network error). UrlRequest::Open / SendAsync would dispatch to the registered resolver when the scheme matches, so StatusCode() / ResponseBuffer() / GetResponseHeader("content-type") / error reporting all work through the existing UrlRequest surface. (UrlLib has issues disabled, so this is tracked here.)
2. JsRuntimeHost: register the URL polyfill's object-URL store as the blob: resolver and remove the per-polyfill blob: branches in Polyfills/Fetch/Source/Fetch.cpp and Polyfills/XMLHttpRequest/Source/XMLHttpRequest.cpp.

The object-URL store itself stays in the URL polyfill; only the resolution moves behind UrlLib via the registered callback.

Related

• Node-API-JSC: napi_typeof reports napi_object for JSObjectMakeConstructor constructors #194 — Node-API-JSC napi_typeof for DefineClass constructors (fixed in Add blob: URL support to URL.createObjectURL / revokeObjectURL #207).
• Per-environment lifetime for the object-URL store needs napi_add_env_cleanup_hook, which the JSC and QuickJS adapters don't implement; that gap is independent of this scheme-resolver work and keeps the store process-global for now.

[bkaradzic-microsoft]

Fixed by #207 (merged 2026-07-28) — the PR was reworked to take exactly the scheme-resolver direction proposed here rather than the per-polyfill branches it originally had.

Both hops are done:

1. Upstream — UrlLib::UrlRequest::RegisterSchemeResolver was added in Add pluggable URL scheme resolver (e.g. blob:) to UrlRequest UrlLib#37, so a registered callback is dispatched from UrlRequest when the scheme matches and StatusCode() / ResponseBuffer() / GetResponseHeader("content-type") / error reporting all work through the existing UrlRequest surface.
2. JsRuntimeHost — Polyfills/URL/Source/URL.cpp registers the object-URL store as the blob: resolver exactly once (a hit yields 200 with the stored content-type; a miss or revoked URL yields a network error). The blob: special-cases are gone from Polyfills/Fetch/Source/Fetch.cpp and Polyfills/XMLHttpRequest/Source/XMLHttpRequest.cpp, so fetch, XHR and any other UrlRequest consumer (image/video src, texture loaders) resolve blob: uniformly with no per-polyfill interception.

The object-URL store stayed in the URL polyfill, as proposed. The remaining per-environment-lifetime concern is tracked separately in #215.

Closing as completed.