managing-frame-forward-lifecycle
Installation
SKILL.md
Managing frame-forward lifecycle
Overview
A forwardFrames registration cleans itself up. It prunes its own entry when the target dies, unhooks its own listener when disposed, and refuses to register at all when registration could not self-clean. Bookkeeping layered on top is redundant — and the listener bookkeeping is itself the leak people write it to prevent.
The contract
| Situation | The library already does this | You do |
|---|---|---|
Target WebContents destroyed later (its window closed) |
Entry is auto-pruned via an internal once("destroyed") — no forwarding to a dead target |
nothing |
forward.dispose() |
Deletes the entry and removes that internal "destroyed" listener from your target. Idempotent, never throws, safe after the target died |
call it (see below) |
bridge.dispose() |
Unhooks every entry's listener, then clears all entries | nothing |
forwardFrames() after bridge.dispose() |
Does not register; returns an inert FrameForward whose dispose() is a no-op and whose active is false |
see "own the truth" below |
forwardFrames() with an already-destroyed target |
Same — inert handle, active: false, no registration, no leak |
same |
| A live registration stops delivering (target dies mid-session, import or send fails) | Reports the change on "forwardStatus" / options.onStatus, and keeps trying every frame |
log both edges (see 4) |
Repeated connect/disconnect on one long-lived multiviewer window accumulates nothing: each dispose() takes its listener with it.