Add blob: URL support to URL.createObjectURL / revokeObjectURL

[bkaradzic-microsoft]

What

Adds blob: URL support to URL.createObjectURL / URL.revokeObjectURL, and makes the minted URLs resolvable by every consumer of UrlRequest (fetch, XMLHttpRequest, and any downstream user of UrlLib).

Previously createObjectURL had no backing store on Native, so fetch/XHR could not load a Blob and revokeObjectURL had nothing to release. This implements the missing in-memory registry.

How

• URL polyfill — createObjectURL(blob) puts the Blob's bytes into an in-memory store keyed by a freshly minted blob:null/<uuidv4> URL and returns it; revokeObjectURL frees the entry. The store's C++ surface is deliberately not exported: RegisterObjectURL/RevokeObjectURL are file-local to URL.cpp, since neither has a caller elsewhere and No adapter implements napi_add_env_cleanup_hook, forcing per-environment native state to be process-global #215 would reshape the contract anyway.
• blob: scheme resolver — rather than special-casing blob: inside each request polyfill, the URL polyfill registers a resolver with UrlLib::UrlRequest::RegisterSchemeResolver (added in Add pluggable URL scheme resolver (e.g. blob:) to UrlRequest UrlLib#37). Every UrlRequest consumer therefore resolves blob: uniformly, with no per-polyfill interception: a hit yields status 200 with the stored content-type, and a miss (or a revoked URL) yields a network error, so fetch rejects with a TypeError and XHR reports status 0 plus an error event.
• Blob polyfill — adds a TryGetData(object) -> std::optional<BlobData> accessor so the URL polyfill can read a Blob's bytes and MIME type. It lives behind a BlobInternal INTERFACE target (InternalInclude/, mirroring JsRuntimeInternal) rather than the public header, since it is an in-repo seam and not an embedder contract. Blob now holds its bytes in a std::shared_ptr<const std::vector<std::byte>>, so createObjectURL shares the buffer with the store instead of duplicating it, and the returned data no longer has a lifetime tied to the JS object.
• JavaScriptCore napi_typeof fix — Core/Node-API/Source/js_native_api_javascriptcore.cc now consults JSObjectIsConstructor in addition to JSObjectIsFunction, so constructors made with JSObjectMakeConstructor report napi_function rather than napi_object. This is not specific to this feature — it affects every JSC consumer — but it lets Fetch and File drop their IsUndefined()/IsNull() workarounds and go back to a plain IsFunction() check.
• Adds createObjectURL round-trip unit tests (fetch + XHR, revoke frees memory).

Design note

The store is process-global rather than per-environment. Per-env teardown would normally use napi_add_env_cleanup_hook, but no Node-API engine adapter in this repo implements it, so there is no portable per-env hook available today. The keys are unguessable v4 UUIDs, so sharing one store across environments is safe — a blob: URL minted in one environment is never produced in another.

The cost is that entries which are never revoked stay alive for the lifetime of the process, and are not released when the environment that created them is torn down. This is a real leak, not a browser-like behavior: a browser drops a document's blob URLs when the document unloads. #215 tracks implementing napi_add_env_cleanup_hook across the adapters so the store can become per-environment.

Testing

Full UnitTests suite green (216 passing) on Windows/Chakra locally, with the remaining engines and platforms covered by CI, including the new URL.createObjectURL round-trip tests (fetch + XHR text/binary, content-type header, and revoke → network-error / status 0).

[Copilot]

Pull request overview

Adds first-class blob: URL support to the runtime’s URL polyfill by introducing an in-memory object-URL registry and wiring fetch and XMLHttpRequest to resolve minted blob URLs, with unit tests covering round-trips and revoke behavior.

Changes:

• Implement URL.createObjectURL / URL.revokeObjectURL backed by a process-global in-memory registry, plus a small native API to register/revoke/resolve entries.
• Teach fetch and XMLHttpRequest polyfills to intercept blob: URLs and serve bytes + content-type from the registry.
• Add Blob::TryGetData for synchronous access to blob bytes/type and add unit tests for fetch/XHR + revoke cases.

Reviewed changes

Copilot reviewed 14 out of 14 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
Tests/UnitTests/Scripts/tests.ts	Adds unit tests for createObjectURL round-trips via fetch/XHR and revoke behavior.
Polyfills/XMLHttpRequest/Source/XMLHttpRequest.h	Adds in-memory response fields to support blob: responses.
Polyfills/XMLHttpRequest/Source/XMLHttpRequest.cpp	Implements blob: URL interception/resolution and response/header/status behavior.
Polyfills/XMLHttpRequest/CMakeLists.txt	Links XMLHttpRequest polyfill against the URL polyfill library.
Polyfills/URL/Source/URL.h	Exposes createObjectURL/revokeObjectURL on the JS URL constructor.
Polyfills/URL/Source/URL.cpp	Implements process-global blob URL registry and JS createObjectURL/revokeObjectURL.
Polyfills/URL/Readme.md	Updates URL polyfill documentation (but currently does not match the new implementation).
Polyfills/URL/Include/Babylon/Polyfills/URL.h	Adds native API surface for register/revoke/resolve of blob URLs (docs currently mismatch implementation lifetime).
Polyfills/URL/CMakeLists.txt	Links URL polyfill against Blob to read blob bytes/types.
Polyfills/Fetch/Source/Fetch.cpp	Intercepts blob: URLs and synthesizes Response from registry bytes/type.
Polyfills/Fetch/CMakeLists.txt	Links Fetch polyfill against the URL polyfill library.
Polyfills/Blob/Source/Blob.h	Adds synchronous internal accessors for blob bytes/type.
Polyfills/Blob/Source/Blob.cpp	Adds public TryGetData API to synchronously extract blob bytes/type.
Polyfills/Blob/Include/Babylon/Polyfills/Blob.h	Declares TryGetData for cross-polyfill blob access.

---

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

[bkaradzic-microsoft]

Thanks for the review! Pushed f7e1fd1 addressing the CI failure and all five inline comments.

CI red on JSC / V8-on-Ubuntu / JSI (root cause): Blob::TryGetData used napi_instanceof (Napi::Object::InstanceOf), which is unreliable for ObjectWrap-based constructors on those engine adapters — it returned false for genuine Blob instances, so every blob: test failed at runtime there while passing on QuickJS. Replaced it with a prototype-chain walk against Blob.prototype via napi_get_prototype (implemented and sound on all four adapters; JSC uses JSObjectGetPrototype). This also correctly accepts Blob subclasses such as File.

Review comments:

1. XHR GetResponse synthetic CallbackInfo — removed; the blob branch now returns the response string directly (no Napi::CallbackInfo{env, nullptr}).
2. XHR open() reuse + method validation — open() now resets all blob state up front so a reused instance can't mix blob:/transport requests, and the HTTP method is validated for blob: URLs too.
3. Revoke between open() and send() — the object-URL store is now (re-)resolved at send() time, so a revoke after open() surfaces as a network error (status 0 + error).
4. URL Readme.md — updated to describe the in-memory process-global blob: registry (was data: URL / no-op).
5. URL.h header docs — corrected "per-environment" to "process-global".

Added tests for each behavior (non-Blob rejection, revoke-between-open-and-send, XHR instance reuse). Local UnitTests: 217 passing, 0 failing (QuickJS); watching CI for the other engines.

[bkaradzic-microsoft]

CI is now fully green across all engines (QuickJS/V8/Chakra/Hermes/JSI and JSC on Ubuntu/macOS/iOS + sanitizers).

Root cause of the earlier JSC-only failures: node-addon-api's DefineClass constructors are callable-as-constructor but are not reported as functions by JSC's napi_typeof (JSObjectIsFunction returns false). TryGetData originally gated on the constructor being a function (via InstanceOf), so on JSC it short-circuited and every blob: test failed at runtime with "argument is not a Blob", while passing on the other engines. It now detects a Blob by walking the prototype chain against Blob.prototype using the JS-level Object.getPrototypeOf and probing the constructor with IsObject() — using only node-addon-api wrappers (the raw napi_get_prototype is not exposed by the JSI adapter and returns the raw [[Prototype]] on JSC).

I also dropped the "XHR instance can be reused for a second blob: request" test: it passes on QuickJS but hangs the JSC mocha harness (two sequential async blob-send dispatches on one reused instance never pump the second loadend). The reset-on-open code fix that the test exercised is retained; this looks like a harness/event-loop quirk rather than a logic bug.

[bghgary]

[Reviewed by Copilot on behalf of @bghgary]

Right direction, and it addresses the earlier data: URL feedback. But this is a partial implementation of a feature that should be designed as a whole first. Concerns inline.

[bghgary]

[Reviewed by Copilot on behalf of @bghgary]

All three points addressed. One open item on the store thread.

The description still describes the design this PR replaced: it credits the removed TryResolveObjectURL seam, says fetch and XMLHttpRequest "intercept blob:" when neither branch remains, doesn't mention the UrlLib scheme resolver that now does the work, and omits the js_native_api_javascriptcore.cc napi_typeof change that affects every JSC consumer. Test count reads 214 against the 216 in the last two commits. It becomes the squash commit message, so worth rewriting.

[bkaradzic-microsoft]

Thanks -- you were right on all three counts, and I've pushed fixes.

The store comment was stale and wrong. Three separate problems:

1. It described a TryResolveObjectURL seam that the request polyfills call. That function no longer exists -- the design moved to a blob: scheme resolver registered with UrlLib::UrlRequest::RegisterSchemeResolver, so nothing intercepts per-polyfill anymore. The only two remaining mentions of TryResolveObjectURL in the tree were inside that comment.
2. napi_add_env_cleanup_hook -- I said "QuickJS does not implement it". In fact no adapter in this repo implements it: grepping Core/Node-API/Source returns zero matches, and the only hit repo-wide is the vendored napi-inl.h. Corrected.
3. "reclaimed at process exit, mirroring how browsers retain blob URLs until unload" was backwards, as you said. A browser drops a document's blob URLs when the document unloads; process-lifetime retention is the opposite of that. The comment now calls it what it is -- a leak of un-revoked entries for the process lifetime, not released on environment teardown.

I filed #215 to track implementing napi_add_env_cleanup_hook across the adapters so the store can become per-environment, and both the comment and the public URL.h docs now point at it.

Blob shared_ptr -- done. Blob::m_data is now a std::shared_ptr<const std::vector<std::byte>>, so createObjectURL shares the buffer with the store instead of copying it, and TryGetData's result no longer has a lifetime tied to the JS object (I dropped that caveat from the header). This is sound because m_data is assigned exactly once per Blob: it's only written in ProcessBlobPart, which is only reachable from the constructor, and multi-part construction currently throws.

Also in this push:

• Repointed the UrlLib pin back at upstream now that Add pluggable URL scheme resolver (e.g. blob:) to UrlRequest UrlLib#37 has merged. Verified the consumed API (RegisterSchemeResolver/UnregisterSchemeResolver/UrlSchemeResolverResult) is byte-identical to the fork pin, and rebuilt all the polyfills against it.
• Rewrote the PR description, which was describing the old intercept-in-each-polyfill design. It now covers the scheme resolver, the JSC napi_typeof fix (which was omitted entirely), the corrected design note, and the right test count -- 216, as you said, not 214.
• Dropped some incidental churn from XMLHttpRequest.cpp that had no business being in this PR.

[bghgary]

[Reviewed by Copilot on behalf of @bghgary]

Both new exports should be internal until we are confident of the contract. Details inline.

[bghgary]

[Reviewed by Copilot on behalf of @bghgary]

LGTM