Background
Found and partly fixed 2026-07-26 producing example recordings for the
README. recording.js's Recorder class used CCapture
(js/vendor/build/CCapture.all.min.js) for every format. Two separate
bugs found:
- webm was completely broken -- CCapture's webm encoder mux-es
per-frame WebP images (canvas.toDataURL("image/webp")), which
Safari has never supported from a canvas -- fails silently there,
producing a 243-byte (effectively empty) file every time regardless
of recording length. Fixed: webm now uses the browser's native
MediaRecorder API (canvas.captureStream() +
new MediaRecorder(stream, {mimeType: "video/webm"})) instead of
CCapture -- no WebP involved, confirmed producing real multi-MB
files. gif/png/jpg are unaffected by this specific bug and still use
CCapture.
Swift.stop_recording() never reset self.recording = False --
a second start_recording() call in the same session always raised
"You are already recording", even though the first recording had
genuinely already stopped. Fixed.
- Separately:
gif.worker.js (needed by CCapture's gif/webm encoders,
loaded at runtime as a Worker script) was never vendored -- only
shipped under ccapture.js's src/, not build/. Fixed (vendor
script + rerun).
Still broken, not yet fixed: after fix #3, GIF encoding genuinely
runs (confirmed via CCapture's own status overlay showing real frame
counts, e.g. "CCapture gif | 640 frames | 00:00:32"), but .save()
never triggers an actual browser download -- no file ever appears, and
there's no visible save/download control in that overlay to click
either. Not root-caused: could be an async encoding step that never
completes, or a broken/no-op internal call to whatever download helper
CCapture normally uses.
Proposed fix
Either root-cause CCapture's gif save path specifically (would need to
step through the minified bundle or find an unminified source), or
replace it the same way webm was replaced -- record a MediaRecorder
webm and convert to gif via an external tool/service, or find a modern
maintained gif-encoding library to vendor instead of ccapture.js
(unmaintained, last released ~2017, predates MediaRecorder being
universal). The latter is probably the more durable fix long-term,
consistent with the "modern, no framework, current dependencies"
direction the rest of the 2026 rebuild took.
Background
Found and partly fixed 2026-07-26 producing example recordings for the
README.
recording.js'sRecorderclass used CCapture(
js/vendor/build/CCapture.all.min.js) for every format. Two separatebugs found:
per-frame WebP images (
canvas.toDataURL("image/webp")), whichSafari has never supported from a canvas -- fails silently there,
producing a 243-byte (effectively empty) file every time regardless
of recording length. Fixed: webm now uses the browser's native
MediaRecorderAPI (canvas.captureStream()+new MediaRecorder(stream, {mimeType: "video/webm"})) instead ofCCapture -- no WebP involved, confirmed producing real multi-MB
files. gif/png/jpg are unaffected by this specific bug and still use
CCapture.
Swift.stop_recording()never resetself.recording = False--a second
start_recording()call in the same session always raised"You are already recording", even though the first recording had
genuinely already stopped. Fixed.
gif.worker.js(needed by CCapture's gif/webm encoders,loaded at runtime as a Worker script) was never vendored -- only
shipped under
ccapture.js'ssrc/, notbuild/. Fixed (vendorscript + rerun).
Still broken, not yet fixed: after fix #3, GIF encoding genuinely
runs (confirmed via CCapture's own status overlay showing real frame
counts, e.g. "CCapture gif | 640 frames | 00:00:32"), but
.save()never triggers an actual browser download -- no file ever appears, and
there's no visible save/download control in that overlay to click
either. Not root-caused: could be an async encoding step that never
completes, or a broken/no-op internal call to whatever download helper
CCapture normally uses.
Proposed fix
Either root-cause CCapture's gif save path specifically (would need to
step through the minified bundle or find an unminified source), or
replace it the same way webm was replaced -- record a
MediaRecorderwebm and convert to gif via an external tool/service, or find a modern
maintained gif-encoding library to vendor instead of
ccapture.js(unmaintained, last released ~2017, predates
MediaRecorderbeinguniversal). The latter is probably the more durable fix long-term,
consistent with the "modern, no framework, current dependencies"
direction the rest of the 2026 rebuild took.