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. Same change as NativeScript/ios#548.

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, so a character straddling a boundary came out as two U+FFFD in sourcesContent. Breakpoints still bound (mappings are ASCII); 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 none was sent, so every map it loaded stayed in memory until the debugger disconnected.
• offset was ignored, so 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, which ran ahead of the real position whenever a character was split.

Three choices differ from a literal copy of Chrome:

• Headers. Chrome's file:// loader sends no Content-Length, so Chrome has the same js-debug leak for file-backed maps. The reply here carries what an HTTP server would send for the file.
• 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 to keep socket frames and peak memory small on device.

Streams are still dropped on every disconnect: connect() always runs disconnect() first, and websocket close and error both call it. That matches Chromium's DiscardAllStreams on detach.

Text chunks now carry raw UTF-8, including 4-byte sequences, back to Java through NewStringUTF, like the V8 inspector messages already do. CheckJNI raised no complaint on API 33.

Testing

• Device suite on a ci_repro_api33 arm64 emulator, run twice: 238 suites, 1468 tests, 0 failures, 4 skipped.
• An end-to-end CDP client (not committed) over the forwarded <pkg>-inspectorServer websocket, 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 reassembles every map exactly with no U+FFFD, and its IO.close succeeds.
  • DevTools' readToBuffer loop reassembles text and binary exactly.
  • Every chunk ends on a character boundary.
  • Seeks, negative offset, past-the-end eof, 7-byte round trips.
  • Reads that cut a character come back as base64 with the exact bytes; 3-byte reads round-trip byte-exactly.
  • int32 and size validation; unknown-handle errors.
  • A stream left open is gone after the client disconnects.

Not changed here, pre-existing: AndroidJsV8Inspector.onException calls exception.getMessage().equals(...), which throws a (caught) NullPointerException when a client drops the socket without a close frame.

Summary by CodeRabbit

• Bug Fixes
  • Improved resource reads with optional positions and sizes, consistent chunking, and support for text and binary content.
  • Invalid read parameters and unknown stream handles now return errors instead of being treated as successful requests.
  • Text reads avoid splitting UTF-8 characters, and end-of-stream reads are handled more consistently.
  • Loaded resources now include content length and JSON content-type information.