DEV Community: Sahil Nasariwala

How I built auto-zoom-on-click screen recording inside a Chrome extension

Sahil Nasariwala — Mon, 12 Oct 2026 09:05:28 +0000

Screen recordings of a web app are hard to watch. The interesting part, the button you clicked, is a few dozen pixels on a 1440p frame. Tools like Screen Studio fix this by zooming in on every click, but they're desktop apps. I wanted that inside Chrome, with nothing uploaded anywhere, so I built Bimb, a Chrome extension that records a tab and turns every click into a smooth zoom.

Here's how the pieces fit together, including the parts that took the longest to get right.

1. Recording in Manifest V3

An MV3 extension has a service worker, not a background page, and a service worker can't run MediaRecorder. So recording happens in an offscreen document:

Tab recording: the service worker gets a stream id from chrome.tabCapture, and the offscreen document turns it into a MediaStream and records it.
Window or screen recording: I first tried chrome.desktopCapture, but its stream ids are tied to the frame that asked for them, so the offscreen document couldn't use one requested elsewhere. The offscreen document now calls getDisplayMedia() itself and shows Chrome's own picker.

Recordings go into IndexedDB (with the unlimitedStorage permission, so Chrome doesn't evict a long video). Nothing leaves the machine.

2. Knowing where the clicks were

Video alone doesn't tell you where someone clicked. During a tab recording, a content script runs in every frame it can reach and reports pointer events in that frame's viewport coordinates.

Iframes make this harder than it sounds. A click inside an embedded iframe has to be mapped to top-page coordinates, which means knowing which <iframe> element that frame lives in. Chrome has no runtime.getFrameId() (that's Firefox-only), so I use a small handshake:

The child frame registers a random token with the service worker.
It posts only that token to its parent window.
The parent's script matches the message source to an iframe element and tells the service worker it owns that token.

The page can see the token but never any coordinates. Frames can also hide inside closed shadow roots, which chrome.dom.openOrClosedShadowRoot() can reach.

Some pages are off-limits: Chrome doesn't let extensions run scripts on chrome:// pages, the Web Store or other extensions. On those the video still records, but there are no clicks to zoom on.

3. Turning clicks into zooms

Each click becomes a zoom segment, with two rules:

Clicks close in time and space share one segment, and the camera pans between them.
Far-apart clicks get their own zoom. A long pan across the page while zoomed in is disorienting, so it's better to zoom out and back in.

The zoom finishes arriving just before the click and holds a moment after it, so the viewer sees the button before it's pressed.

4. A camera that's a pure function of time

The camera is a function of time t alone: given the zoom segments and t, it returns the visible rectangle. It's built from eased keyframes, then clamped so the view never leaves the frame.

One detail made a big difference: interpolate the zoom level in log space. Going from 1x to 2x should feel the same as going from 2x to 4x, and plain linear interpolation makes zooming in feel fast at the start and sluggish at the end. Simplified:

// simplified: zoom level between two keyframes
const zoomAt = (a: number, b: number, k: number) =>
  Math.exp(Math.log(a) + (Math.log(b) - Math.log(a)) * k);

Because the camera keeps no state, the editor preview and the exported file are computed by the same code from the same inputs, so they can't drift apart.

5. A cursor that doesn't wobble

Raw pointer samples come in at about 60 Hz and are jittery. Smoothing them with a normal filter adds lag, so the drawn cursor arrives at the button after the click has already happened.

Instead, I resample the path at 120 Hz and run a critically damped spring over it forwards, then backwards (zero-phase, like filtfilt in signal processing). The motion is smooth with no lag, and the cursor sits exactly on the click point at click time.

6. Trimming dead time

Most recordings have pauses: you reading, thinking, waiting for a page to load. Bimb finds stretches with no clicks, keys or pointer movement and suggests cutting them. It's plain gap analysis, no ML, and you confirm each cut.

Cuts are non-destructive. One bug worth sharing: cutting a section introduced audio/video drift, because a cut boundary landed between video frames while the audio was cut at the exact sample. The fix was to snap cut spans to frame boundaries and crop audio chunks at those same boundaries.

7. Exporting in the browser

Export runs in a worker:

Decode the source at a constant frame rate.
Draw each frame through the same scene code the preview uses: background, camera, cursor, click ripples, captions and blur regions.
Encode with WebCodecs.

Mediabunny handles demuxing and muxing for MP4 (H.264 + AAC/Opus) and WebM (VP9/VP8 + Opus), and gifenc handles GIFs. A 1440p60 export runs entirely on your machine.

What I'd tell someone building something similar

Make rendering a pure function of time. It turned "the preview doesn't match the export" bugs into ordinary unit tests.
Expect frames and shadow roots everywhere. Real apps (docs sites, dashboards, MDN) nest iframes inside shadow roots.
Read the MV3 limits before designing. Service workers can't record media, and capture ids are tied to a frame. Both changed my architecture.

Bimb is free to record and export with a watermark; Bimb Pro is a one-time license. You can get it on the Chrome Web Store. I'd love feedback, especially from anyone who has fought the same MV3 capture APIs.

I Built an Event Loop Visualizer Because the Best One Is From 2014

Sahil Nasariwala — Wed, 02 Sep 2026 06:22:04 +0000

Every JavaScript developer has seen this:

console.log('start')

setTimeout(() => console.log('timeout'), 0)

Promise.resolve().then(() => console.log('promise'))

console.log('end')

// start → end → promise → timeout

Most of us know the answer.

We know that microtasks run before the next task. We know setTimeout(..., 0) doesn't actually mean "run this immediately." We know promises and the event loop are frequent interview topics.

But then someone gives you a slightly uglier example and asks:

"Okay, what happens next?"

And suddenly you're drawing boxes on a whiteboard.

That's what made me build The Event Loop, Visualized.

It's an interactive course where you can actually watch the call stack, task queue, microtask queue, and Web APIs change step by step. You can slow it down, move backward, scrub through the timeline, and eventually paste in your own JavaScript and watch it get visualized.

But don't we already have event loop visualizers?

Yes.

That's actually where this project started.

Before writing any code, I spent some time looking at what already existed.

The first one everyone knows is Loupe, from 2014. It's still great, and Philip Roberts' "What the heck is the event loop anyway?" talk is one of the resources that made the event loop click for an entire generation of developers.

But JavaScript has changed quite a bit since then.

Promises weren't part of the picture in the same way. async/await didn't exist. Microtasks weren't something most developers were thinking about.

There are newer tools too.

JSV9000 does a good job of showing microtasks and letting you step through execution, but it assumes you already understand what you're looking at.

JSFlow supports promises and async/await, but feels more like a playground than a course.

And then there's Lydia Hallie's JavaScript Visualized series, which is probably the best example of how much people enjoy learning JavaScript through animation. But they're still essentially videos/GIFs—you can't stop at a specific moment and ask, "Wait, why did this move here?"

I kept noticing the same thing:

The tools were either good at teaching or good at experimenting. Not both.

So I decided to try combining the two.

Not another diagram.

Not another article explaining the event loop.

Something you could actually play with.

The first thing I wanted to get right: different explanations, same animation

One thing I didn't want to do was create a "beginner version" and an "advanced version" as completely separate experiences.

Instead, every scene has three levels of explanation.

Explain simply

Think chef, kitchen, and VIP line.

It's deliberately visual and avoids throwing terms like "microtask checkpoint" at someone who has never heard them before.

Developer

Now we talk about the actual things developers work with:

Call stack
Web APIs
Task queue
Microtask queue
Promises
Timers

Under the hood

This is where the browser's actual behavior comes in: task sources, microtask checkpoints, rendering opportunities, and the HTML specification.

The interesting part is that the animation doesn't change.

Only the explanation changes.

That means a beginner and an experienced JavaScript developer can watch the exact same animation and just choose how deep they want to go.

It also turned out to be a useful constraint while building the content. I couldn't accidentally create three slightly different versions of the same lesson.

The architecture decision I liked the most

This is probably the most interesting part of the project from an engineering perspective.

My first thought was to instrument the browser.

Something like:

const originalSetTimeout = window.setTimeout

window.setTimeout = (...args) => {
  // record what happened
  return originalSetTimeout(...args)
}

Intercept timers.

Watch promise callbacks.

Track the call stack.

Emit events as the browser actually executes them.

It sounds reasonable.

It's also a pain if you want an interactive visualizer.

Because now you're trying to control the actual event loop.

You can't simply say:

"Pause the browser right here."

And then:

"Actually, go back three steps."

Or:

"Let's replay this at 0.5× speed."

The browser isn't designed around those controls.

So I stopped trying to record the real event loop.

I decided to record what the event loop should do instead.

A scene is just a script

Instead of treating a scene as executable JavaScript, I represent it as a sequence of small actions.

Something roughly like:

Step 1
→ highlight line 1
→ push "console.log" onto stack
→ print "start"

Step 2
→ register setTimeout
→ move callback to Web APIs

Step 3
→ create promise callback
→ add it to microtask queue

...

The visualizer doesn't care how the scene was created.

It just receives the steps and renders them.

The runtime state at any point can then be calculated from those steps:

export function computeState(
  scene: Scene,
  stepIndex: number
): RuntimeState {
  const state = emptyState()

  for (let i = 0; i <= stepIndex; i++) {
    for (const action of scene.steps[i].actions) {
      state.apply(action)
    }
  }

  return state
}

And suddenly a lot of features became almost trivial.

Want to go backward?

Recalculate the state at the previous step.

Want to jump to step 7?

Calculate step 7.

Want to scrub from step 2 to step 9?

Calculate step 9 and animate the difference.

No undo stack.

No complicated event-sourcing system.

No snapshots.

Most scenes only have around ten or so steps, so recalculating the state is basically free.

That one architectural decision gave me:

Play
Pause
Step forward
Step backward
Scrubbing
Speed control
Deep links to specific steps

Then came the harder question: what about my own code?

Hand-written scenes work really well for lessons.

But eventually the obvious question appears:

"Cool. But can I paste my code into it?"

That was the whole point.

So the playground uses Acorn to parse the JavaScript into an AST and then compiles the supported code into the exact same step format used by the hand-written lessons.

The visualizer doesn't know—or care—whether a scene came from a lesson or from the playground.

It's just a sequence of steps.

For now, the playground supports a deliberately limited subset:

console.log
setTimeout
Promise chains
queueMicrotask
async/await
Function calls

There's also an 80-step limit.

I don't want someone pasting an accidental infinite loop into an educational animation and making the browser regret its life choices.

I also made a mistake here

I didn't build the compiler first.

I built the flagship scenes manually.

promise-vs-setTimeout

Microtask starvation

async/await, unmasked

After building enough of them, I started noticing the patterns.

Only then did I build the compiler.

That turned out to be a much better approach.

If I'd started by designing the compiler, I would have designed an abstraction based on what I thought a scene needed.

After building the scenes, I knew what it actually needed.

Some small things ended up making a big difference

The event loop is the main feature, but a few other decisions made the project feel much more complete.

Prediction mode

Before showing the answer, the site asks you to predict the output.

There's something useful about committing to an answer first.

If you're wrong, you don't just see the correct output—you see exactly where your mental model diverged.

"Break the loop"

There's a small sandbox where you can intentionally block the main thread.

You see an animation running normally.

Then the blocking loop starts.

And the animation freezes.

It's much more memorable than reading:

"Long-running JavaScript can block rendering."

You actually watch the UI stop responding.

Compare snippets

You can run two to four snippets against each other and watch their behavior side by side.

The benchmarks run inside a Web Worker so the comparison doesn't block the very event loop you're trying to understand.

Themes

There are five themes inspired by tools like Monkeytype.

The theme system uses CSS variables, and an inline pre-paint script prevents the page from flashing the wrong theme during startup.

It's a tiny detail.

But once you notice a flash like that, you can't unsee it.

Deep links

You can link directly to a specific point in an animation:

/play/promise-vs-settimeout?step=5&level=simply

So instead of telling someone:

"Go to the promise vs setTimeout example and move to step 5."

You can just send them the exact moment.

I also added keyboard controls and reduced-motion support along the way.

What I'd like to build next

The obvious next step is Node.js's event loop.

Browser JavaScript and Node.js share the same language, but their event loop behavior has important differences.

Phases.

process.nextTick.

setImmediate.

Timers.

I want to put the browser and Node models next to each other and let people experiment with both.

And because the visualizer is based on step scripts rather than browser instrumentation, the underlying architecture doesn't really care which event loop we're describing.

That's probably my favorite thing about the project.

What started as:

"I wish there was a better event loop visualizer."

turned into a small experiment in building interactive technical education.

If you want to try it:

The Event Loop, Visualized

And if you've ever written:

setTimeout(() => {}, 0)

as a fix and then quietly hoped nobody would ask you why it worked...