THE PROBLEM
Bug reproduction in Salesforce is painful. A developer gets a ticket that says "the Opportunity page crashes sometimes" with a screenshot of a spinner. No steps. No console output. No org context. They spend 30 minutes just trying to reproduce it before they can even start fixing it.
We've seen this pattern on every Salesforce project we've worked on. The gap isn't a skills problem — it's a tooling problem. Developers don't have a fast way to capture the full context of a bug: what page, what record, what user actions, what the Lightning component tree looked like, and what errors appeared in the console.
So we built one.
WHAT IT CAPTURES
The Salesforce Screen Recorder is a Chrome extension that sits on any Salesforce Lightning page and — on demand — packages up:
- A screen recording of the reproduction steps, captured via the Chrome tab capture API
- Screenshots at key moments (start, error, end)
- Page metadata — the current URL, record ID, object type, and active app
- Console output — errors, warnings, and debug logs from the Lightning runtime
- Optional: Salesforce debug logs — Apex execution traces, SOQL queries, governor limit usage
Everything gets packaged into a structured ZIP with a manifest.json at the root that describes the contents. That structure matters — it's what makes the ZIP useful for AI-assisted debugging.
THE COPILOT ANGLE
We built the ZIP format with GitHub Copilot Workspace in mind. When you drop a structured ZIP into Copilot, it can reason about the whole context — not just a single file. The manifest.json tells it exactly what's in the bundle, the debug log gives it the Apex trace, and the screenshots give it visual context.
In practice, developers using the extension report that a bug that used to take 30–45 minutes to diagnose takes 5–10 minutes — mostly because the reproduction context is complete before they even open their IDE.
THE ARCHITECTURE
Chrome Manifest V3 is restrictive in ways that made this interesting to build. A few things that shaped the architecture:
- Service workers, not background pages. MV3 replaces persistent background pages with ephemeral service workers. We had to design around the fact that the worker can be killed at any point, using Chrome's storage API to persist state across worker lifecycles.
- Tab capture requires a visible popup. The
chrome.tabCaptureAPI only works from a user gesture in a popup, not from a content script or background worker. The recording flow has to originate from the popup UI. - Debug log retrieval is asynchronous and rate-limited. Pulling debug logs from the Salesforce Tooling API requires an active session and respects per-org API limits. We implemented a polling approach with backoff rather than blocking the ZIP assembly on log retrieval.
The ZIP assembly itself uses the JSZip library running in the popup context. We stream the screen recording directly into the ZIP rather than holding the whole video in memory, which matters for longer recordings on pages with complex components.
WHAT WE LEARNED
The most surprising part of building this wasn't the technical constraints — it was how much of the value came from structure rather than completeness. An unstructured dump of everything is useless. A structured manifest with well-named files that a model can parse is transformative.
That principle has shaped how we think about developer tooling in general: the output of a tool isn't just data — it's data in a shape that the next tool (human or AI) can immediately act on.
The extension is live on the Chrome Web Store. If you're building on Salesforce, try it — it's free.