GeezerVison

Source maps served through nsruntime:// (Network.loadNetworkResource + IO.read/IO.close) now follow Chromium's own implementation (DevToolsStreamFile, IOHandler, NetworkHandler::OnLoadNetworkResourceFinished), so VS Code's js-debug and Chrome DevTools see the same behavior they get from Chrome.

What was wrong

• Split characters. IO.read cut the stream every 1 MB without regard for UTF-8. js-debug decodes each chunk on its own (Buffer.from(data, 'base64').toString()), so a character straddling a boundary came out as two U+FFFD in sourcesContent. Mappings are ASCII, so breakpoints still bound; the source text js-debug showed was garbled.
• Streams never freed during a session. js-debug only sends IO.close when the response has a Content-Length header, and the runtime sent no headers. Every map js-debug loaded (vendor maps can be several MB) stayed in memory until the debugger disconnected.
• offset was ignored. Only clients that read front to back worked.

Behavior now (matches Chromium)

Honoring offset is safe only together with the boundary trimming. js-debug advances its offset by the UTF-8 length of each decoded chunk, so before the trimming, a split character made that offset run a few bytes ahead of the real position.

Three choices differ from a literal copy of Chrome:

• Headers. Chrome's file:// loader sends Content-Type and Last-Modified but no Content-Length, so Chrome itself has the same js-debug leak for file-backed maps. Here the reply carries the headers an HTTP server would send for the file. With Content-Length, js-debug stops after exactly that many bytes and closes the stream.
• Chunks that cut a character. A read that starts inside a character, or one of 6 bytes or fewer, can cut a character at an end. Chrome's JSON encoder drops those bytes. Here that one reply is sent as base64 with the exact bytes (base64Encoded is per reply). js-debug and DevTools never read this way.
• Chunk size. The default stays at 1 MB instead of Chromium's 10 MB. Clients loop either way, and iOS frames are UTF-16 on the wire, so a 10 MB chunk would be a 20 MB+ frame.

Streams are still dropped on every disconnect path (socket close or error, and a new frontend taking over) via ResetFrontendState, like Chromium's DiscardAllStreams on detach. Messages from a replaced connection are discarded under the lifecycle lock, so no stream can be created after that reset.

The same change for Android: NativeScript/android#2091.

Testing

• ./run_tests.sh --keep-sim (iPhone 16 Pro): 1836 specs, 0 failures.
• An end-to-end CDP client (not committed; same approach as fix(inspector): release the frontend's resources when DevTools disconnects #516) against a TestRunner kept alive on the simulator, with generated fixtures: a 5 MB map with a 4-byte emoji straddling the 1 MB boundary, a 3 MB map of mixed 1–4 byte characters, binary data, a map containing U+FFFE, and small and empty maps. 66/66 checks pass:
  • js-debug's read loop (offsets from decoded lengths, stop at Content-Length, then IO.close) reassembles every map exactly, with no U+FFFD.
  • DevTools' readToBuffer loop (no offset, size 1 MB, until eof) reassembles text and binary exactly; binary and noncharacter files come back as base64.
  • Every chunk ends on a character boundary; the first chunk of the 5 MB map stops right before the straddling emoji.
  • Seek, negative offset, seek back to 0, offset past the end; 7-byte reads round-trip; reads that cut a character come back as base64 with the exact bytes, and 3-byte reads round-trip byte-exactly.
  • Parameter errors, including int32 range; read after eof is eof again; read and close after IO.close, and on unknown handles, are errors.
  • A stream left open is gone after the client disconnects, and a new client loads maps normally.

Summary by CodeRabbit

• New Features
  • Resource reads support optional offsets and sizes, defaulting to 1 MiB. Text resources are returned as UTF-8, while binary resources are returned as base64.
  • Loaded resources include content type and length information. Reads at or beyond the end of a resource report end-of-file.
• Bug Fixes
  • Invalid read parameters and handles return protocol errors. Invalid UTF-8 is handled safely, and text chunks are truncated at valid character boundaries when possible.