feat: bring the desktop editor to web by richiemcilroy · Pull Request #2312 · CapSoftware/Cap

richiemcilroy · 2026-09-18T10:14:58Z

Cap web opens the desktop Solid editor for eligible recordings. The browser view shares the desktop editor source and UI; a dedicated worker runs the native preview and exporter. Timeline edits, camera effects, music, captions, image overlays, playback, and export travel through a browser bridge to that worker. The timeline’s Add image and Replace image actions now select a browser file, upload it through the existing signed image asset route, and use the returned project path and dimensions. Desktop image imports still use the local project filesystem.

The web recorder and Chrome extension persist display and webcam as separate synchronized clips, including their start offset. Existing single-track recordings remain editable. Web captions use the existing AssemblyAI options used for shareable-link transcription and are Cap Pro-only at both the client and server boundaries. Desktop captions continue to download and run local models. Preparation and browser-draft recovery errors now render in a Solid view using the desktop editor theme. The web retry and recovery choices return to the Next.js host through the frame bridge, and the fallback keeps the editor background while the error view loads. Normal editor connections now keep the desktop preparation skeleton visible while the full Editor bundle loads; only a pending error view invalidates that mount.

Validation on the exact 1f9a9176 head: an isolated root typecheck, scoped Biome, production Solid bundle, and four full Chromium/WebKit Free/Pro editor replays passed. Each replay downloaded a .capbundle and verified separate display and camera entries; the Pro paths generated AssemblyAI captions, and the Free paths showed the Pro gate without local-model controls. Three repeat WebKit Pro runs and a focused corrupt-frame test passed after the preview WebSocket close-code fix, with no failed requests or page errors in the browser matrix. Chromium/WebKit recovery-error replays and desktop recovery regressions passed on the preceding 6d41f665 head. On this exact head, twelve headed Chrome extension replays passed separate display/camera uploads and start offsets, current-tab capture, recovery of both spools after offscreen recorder closure, two consecutive recordings without stale state, webcam preview startup, countdown, controls, overlay teardown, and start-failure cleanup. The shared recorder-core suite passed 67/67; regular web recorder mock replays and in-editor capture exercised separate recorders. Browser image selection, signed-asset import, native EXIF-oriented JPEG staging, visible overlays, and image preview passed in four-engine/account replays. A local 15-minute 1080p display plus 720p camera fixture without background removal painted about 60 fps in Chromium and WebKit, with matching paused-preview pixel hashes and no browser long tasks. An earlier Linux camera-background-removal benchmark, with the core source unchanged on this head, reached 54.0 fps on an 8-core/6 GiB real-person fixture and 31.1 fps on a saturated 4-core/4 GiB synthetic fixture; sustained 1080p60 with removal is an open performance gate. A 15-minute imported Cap source benchmark prepared a 900-second caption audio stream from a 217 MiB paired-media bundle in 19.9 seconds, with about 100 MiB peak Bun RSS. These are fixture measurements, not a production capacity guarantee. macOS, Linux, and Windows A/V sync tests passed. On this head, GitHub Typecheck, Biome, amd64 and arm64 editor worker builds, Docker images, disposable self-host Compose, and the macOS/Linux/Windows A/V sync matrix and Windows Clippy passed; three desktop builds were still running at this update. The exact-head Greptile review scored 4/5 with no new functional or security finding; its one open thread asks to rename longstanding desktop component files. The exact-head Vercel preview is READY and protected; a signed-in editor session was not exercised.

A signed-in production Next.js editor session, a live paired-capture session in the regular web recorder, and a side-by-side exact pixel comparison with the running desktop app remain unverified. The immediate share-page MP4 and download for a new paired web or extension recording are display-only: ordinary video processing receives the display source, while the saved camera source is available to the editor and can be included when an editor export publishes a replacement. Default share playback with the camera before that export is an open functional-parity gate. The dedicated worker is built but has not been provisioned in the accessible Railway project. Browser APIs also change three OS actions: file clipboard export is disabled where Chromium/WebKit cannot provide a native MP4 clipboard item, downloaded exports have no native Open File action, and desktop wallpaper selection asks the user for an image. Moving H.264 preview frames are lossy; paused previews and exports use the native renderer. The standard self-host Compose test now passes with fixed, multi-architecture Quay MinIO image digests. The Coolify variant parses as YAML but has not been run in a Coolify deployment.

Deployment requires a separate editor worker using apps/media-server/Dockerfile.editor and apps/media-server/railway.editor.toml, the existing MEDIA_SERVER_WEBHOOK_SECRET, CAP_WEB_EDITOR_PUBLIC_ORIGIN, and CAP_WEB_EDITOR_WORKER_URL or CAP_WEB_EDITOR_WORKER_POOL on Next.js. The worker keeps live sessions in memory and should run one replica per worker ID. No database migration is required.

Confidence Score: 4/5

No new functional or security defect was found, but the outstanding repository filename-convention requirement must still be satisfied before merging.

Findings

Component Filename Violates Convention ▶

Fix with agent prompt

### Issue 1
apps/desktop/src/routes/editor/CaptionsTab.tsx:undefined-89
This changed component remains in the PascalCase-named `CaptionsTab.tsx` file, but the repository guide requires filenames to use kebab-case. Rename the file and update its imports. The same violation appears in `ConfigSidebar.tsx`, `ExportPage.tsx`, and other modified desktop editor component files. This repository requirement must be satisfied before merging.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This revision completes browser recording-bundle downloads and corrects malformed preview-frame WebSocket closure behavior.

Routes the desktop editor’s recording-bundle action through the web download bridge with user-visible error handling.
Exercises the downloaded .capbundle and validates its display and camera entries in the Solid browser replay.
Uses an application-defined WebSocket close code for invalid compressed frames and adds regression coverage.
No new correctness or security findings were identified in the changes since the previous review.

_{Reviews (15) · Last reviewed commit: "docs: explain separate webcam capture in..."}

superagent-security

Superagent found 2 security concern(s).

richiemcilroy · 2026-09-18T12:14:34Z