Repository navigation
[Bug]: macOS — after Hide desktop icons drops the pick, the next take records the previous window without asking #1013
Description
What happens
On macOS 15.2+ (Apple's source picker), changing Hide desktop icons in Record mode clears the Source row to "Choose what to record", as intended — but the next Start recording does not ask for a source. The HUD came back showing subject.txt (a window picked earlier in the same picker session) and recorded that window straight away.
Sequence: earlier take picked the TextEdit window → Record mode → picked Share Entire Screen (Source row: "Virtual 1080p") → toggled Hide desktop icons On (row: "Choose what to record") → Start recording → countdown and recording of subject.txt, no picker.
Expected
After the pick is dropped, the next take opens Apple's picker first (checklist "Apple's source picker", line 781).
Steps
- Take 1: pick a window in Apple's picker, record, stop.
- Record mode: Source → pick the entire screen.
- Toggle Hide desktop icons.
- Start recording.
Environment
v2.0.0 (DMG), macOS 27.0, Mac mini M1. recording-settings.json afterwards held lastSource: {kind: "window", name: "subject.txt", id: "mac-picker:window:1190"}.
Activity
EtienneLescot commentedon Oct 7, 2026
Diagnosis (code reading on Windows, not run on a Mac)
No defect found in the main process or the renderer. Toggling Hide desktop icons clears the selected source in the main process (the recording-prefs callback in
handlers.ts) and tells every window. After that,get-selected-sourceanswers null, and the HUD's auto-start opens the picker and waits for its answer. Nothing reads the old pick still held in memory:start-native-mac-recordingonly reads it when the request names a picker source, and that source comes fromget-selected-source, now null. The settings file is re-read on every write, so no stale copy is written back.So the window came back as a new answer from Apple's picker.
lastSourcehad been overwritten by the Record mode screen pick ("Virtual 1080p") and ended assubject.txt(window 1190). The only path that writes a picker source there is apicker-selectedevent arriving while a picker is open (presentMacSystemPicker). Either Apple's picker answered by itself with the earlier window (macOS 27.0), or a click landed on that window while the picker was up but hidden from the screenshots (the picker belongs to a system process, which screenshots mask unless it is granted).Next step (needs a Mac). Reproduce on macOS 27 with the picker's process granted, logging the helper's output to compare the timing of
picker-presentedandpicker-selected. If Apple answers by itself, the fix is in Swift: resetSCContentSharingPicker.shared.isActivebeforepresent(), or ignore an answer that arrives before the user could act.🤖 Generated with Claude Code