[Bug]: reopening a project recorded without camera and microphone crashes (Windows 11)

[EtienneLescot]

Reported privately by a user, reproduced on their machine, not reproduced here yet. Filing it because the path it touches has already produced one bug, and because a project that will not reopen is the worst class of failure this app has.

What they described

Suis arrivé à faire planter openscreen: si tu enregistres sans activer la cam ni le micro, et que tu rouvres le projet, ça plante chez moi.

• Windows 11
• version reported as "1.18", which does not exist. Most likely 1.8.0; to be confirmed
• record with no camera and no microphone, close, reopen the project, crash

What is missing, and worth asking for

• the exact version from Help / About
• what "plante" looks like: the window disappears, or an error is shown, or it hangs on a blank editor
• whether the project reopens after a restart, or fails every time
• whether the same recording with the camera enabled reopens fine, which would isolate the variable

Why this is plausible rather than surprising

The "project with no camera track" path already produced #265 (Export uses the screen recording as the webcam when a project has no camera track). Same family: code that assumes a camera asset exists and falls back to the screen recording when it does not.

That fallback shape is still visible in the editor and CLI export paths:

webcamPath: cam?.sourcePath ?? asset.originalPath,

ExportDialog.tsx:79 and CliExportRunner.tsx:91. Whether that is the same defect #265 fixed or a surviving instance of it needs checking rather than assuming, but it is the first place to look.

NativeCompositorOverlay.tsx handles the empty case differently again:

const webcamPath = cam && cam.visible && cam.sourcePath ? cam.sourcePath : "";

So there are at least two conventions in the codebase for "this project has no camera": an empty string in one place and a substituted screen recording in another. A reopen path that expects one and receives the other is a credible crash.

Microphone absence should be checked as its own variable. The report has both disabled at once, so it is not yet known whether either alone is enough.

Why it matters more than its frequency suggests

Recording without a camera is not an edge case, it is the default for anyone capturing a screen demo. And the failure lands at reopen, which means the recording exists on disk and the user cannot get to it. Even if the crash is trivial to fix, that combination deserves a regression test that creates a camera-less, microphone-less project and reopens it.

[EtienneLescot]

Details from the reporter, and a code path that fits them.

What they added

• single screen, on a laptop, so this is not a multi-monitor arrangement
• the window disappears. Not an error dialog, not a broken editor: the process dies
• the crash was with camera off and microphone off; they are retrying with camera off and microphone on to isolate which one matters

"The window disappears" is the useful part. A JavaScript error in the renderer leaves a broken interface behind, it does not take the window with it. A vanished window points at the main process or at native code.

A native path that matches

NativeCompositorOverlay.tsx:200 uses an empty string to mean "this clip has no camera":

const webcamPath = cam && cam.visible && cam.sourcePath ? cam.sourcePath : "";

That value crosses into the native compositor unchanged, through set_active_clip (crates/compositor-view-napi/src/lib.rs:216) and into open_and_seek_clip:

let mut wdec = match Decoder::open(webcam_path, gpu) {
    Ok(d) => d,
    Err(_) => Decoder::open(screen_path, gpu)?,
};

So when there is no camera, the empty path fails to open and the compositor opens the screen recording a second time and uses it as the webcam decoder.

That is #265 exactly — Export uses the screen recording as the webcam when a project has no camera track — surviving in the live preview path after being fixed in the export path. Two decoders on the same file, and a 1080p screen recording driven as a webcam texture, on a machine with modest graphics.

To be clear about what is and is not established: the substitution is confirmed by reading the code. That it is what kills the process is not. It is a lead that fits the symptom, the configuration and the timing, and it is the first thing to instrument.

Suggested order

1. Reproduce with a camera-less project and watch whether the process dies inside the native compositor rather than in JS
2. Whatever the answer, fix the substitution: falling back to the screen recording when a clip has no camera is wrong on its own terms, and it was already fixed once elsewhere
3. Make the empty-string convention explicit at the boundary. A None that the native side must handle is harder to get wrong than a "" that happens to fail an open

Still worth having from the reporter

The camera-off / microphone-on result, which separates the two variables, and the exact version from Help / About.

[github-actions]

Fixed by #349 and merged into main.

This change is assigned to the Next Release release milestone and is not necessarily available in the latest downloadable desktop release yet. It is currently marked as status: pending release until a packaged release containing it is published.