I'm building a JavaScript debugger called Wirebrowser. It combines network inspection, request rewriting, heap snapshots, and live object search.
The main experimental feature is BDHS (Breakpoint-Driven Heap Search): it hooks into the JavaScript debugger and automatically captures a heap snapshot at every pause and performs a targeted search for the value or structure of interest. This reveals the moment a value appears in memory and the user-land function responsible for creating it.
Another interesting feature is the Live Object Search: it inspects runtime objects (not just snapshots), supports regex and object similarity, and lets you patch objects directly at runtime.
Whitepaper: https://fcavallarin.github.io/wirebrowser/BDHS-Origin-Trace
Feedback very welcome, especially on whether BDHS would help your debugging workflow.
I sometimes find these tools crash hard when pushed via large memory items, huge blobs of code, long base64 strings etc. Even chrome dev tools crash hard on large WS Messages.
Also perhaps post the video near the top instead of hiding it in the origin paper :), kids like videos these days.
Good point about the video ;) I’ll surface it more prominently, the whitepaper ended up a bit dense, so having the visual demo earlier probably helps a lot.
Wirebrowser started as an experiment to unify those workflows and make it possible to follow those values directly instead of stitching together multiple tools. It grew from the pain points I kept running into.
The browser’s debugging API (CDP) also doesn’t provide a way to capture or rewind engine state without modifying the application.
BDHS works within the constraints of zero instrumentation: it relies only on Debugger.paused and heap snapshots, so it can trace where a value originates without altering the code being debugged.
I am working on doing something similar in C++, where there is an additional obstacle of recreating the objects from a memory snapshot without runtime support.
Doing similar work in C++ is on a totally different level: raw memory, no type info, pointer chasing, layout inference... Very curious to hear how you’re approaching it.
Nice work!
Wirebrowser sits at the other end of the spectrum: it attaches to any unmodified browser that supports CDP and works directly with the live runtime. The workflows end up being very different, but it’s fascinating to see what becomes possible when the runtime itself participates in the recording.
Wirebrowser comes at it from a different angle - no instrumentation, just inspecting the live heap and following how values propagate. Curious to see what people end up exploring with these approaches.