feat(audio): warn and disable recording when no input device detected…#1000
feat(audio): warn and disable recording when no input device detected…#1000Luke-Bilhorn wants to merge 9 commits into
Conversation
…#980) Add useAudioInputDevices hook that enumerates audioinput devices and listens for `devicechange` events so plugging/unplugging a mic updates the UI live. When no device is present, the recorder button is disabled, its tooltip reads "No microphone detected", and an inline warning row appears below the button. Includes a `window.__forceNoAudioInput` debug flag for QA on machines with a working mic.
) Visual polish for the no-microphone state: - Add an `unavailable` prop to RecorderCircle that's distinct from `disabled` so the locked-cell visual (faded primary mic) is preserved while the no-mic state gets a solid mid-grey circle with a white MicOff (slashed) icon and no pulse animation. - Replace the inline AlertTriangle hint with a ShadCN Alert box matching the existing yellow-warning pattern used in the source importer forms. Constrained to `w-fit` so it hugs its text and centers under the mic. Hook robustness: - Capture `navigator.mediaDevices` at effect mount so the cleanup path removes its listener from the original reference, even if the global is swapped out later (tests, hot-reload, polyfills). Tests: - 5 unit tests for useAudioInputDevices covering presence, absence, live `devicechange` hot-plug, the `__forceNoAudioInput` debug flag, and graceful fallback when `enumerateDevices` is unavailable. - 1 integration test asserting the record button disables, the warning renders, and `getUserMedia` is never reached when no device exists.
|
…ice-is-not-detected
|
Claude's instructions for how to test with a working mic (or just ask agent to use forceNoAudioInput lol) Testing the no-microphone UI with a working mic
To restore the normal state: window.__forceNoAudioInput = false;
navigator.mediaDevices.dispatchEvent(new Event("devicechange"));The flag is intentionally left in production code (documented in |
|
/build |
|
Pre-release: 0.27.0-pr1000-f266a5c https://github.com/genesis-ai-dev/codex-editor/releases/tag/0.27.0-pr1000-f266a5c |
…ice-is-not-detected
…ice-is-not-detected
There was a problem hiding this comment.
Doesn't seem to work for me. I tried removing permissions (which would be an ideal case for this warning to come up for as well) and disabling using the debug commands. I am working on a mac.
Also, please check the padding difference from the top to the bottom of the warning section. Also the margin between the icon and the text in the warning message as it is also not vertically aligned.
|
|
…#980) - Suppress countdown/recording on auto-start when mic unavailable - Center alert icon/text - add FORCE_STATE_FOR_REVIEW for testing - Add hook + integration tests Attempted but still needing more work - Detect mic permission-denied and detect no-device mic (separately) Still haven't gotten either of these to work.
…ication Chromium's Permissions API only reports browser-level state, not OS-level permission. On macOS, for example, denying microphone access in System Settings still returns "granted" from navigator.permissions.query — so the hook never flipped to permission-denied without an actual record attempt. Expose `reportRecorderError(err)` from useAudioInputDevices and call it from startActualRecording's catch block. The hook classifies common error names (NotAllowedError, NotFoundError, etc.) and pins availability to the matching state. A successful getUserMedia clears the override so the UI recovers automatically after the user fixes permissions and retries.
…ice-is-not-detected
|
Matt, I have fixed all of the things we discussed:
I have tested it and found that we are now correctly getting the OS-level permission (see last commit message), but I have no way to verify that we will be correctly getting the OS-level state for a device with no mic. I think it's pretty likely we are because it is the same type of thing, but this is information I can't learn from my own device. Even if we can't test this before Thursday, I think we should still merge it because the case about no permission is way more important. What Claude says: Expose |
TestingThe yellow warning has two variants: "No microphone detected" (no audio input hardware) and "Microphone access denied" (a mic exists but is blocked). Both render the same grey, slashed-mic button. To force either state without unplugging hardware or revoking permissions, edit line 41 of const FORCE_STATE_FOR_REVIEW: MicAvailability | null = null;Replace "no-device";
"permission-denied";Then rebuild and reload: cd webviews/codex-webviews && pnpm run build:CodexCellEditorHit Once forced into either state, also verify:
|
…ice-is-not-detected
2 participants
… (#980)
Add useAudioInputDevices hook that enumerates audioinput devices and listens for
devicechangeevents so plugging/unplugging a mic updates the UI live. When no device is present, the recorder button is disabled, its tooltip reads "No microphone detected", and an inline warning row appears below the button.Includes a
window.__forceNoAudioInputdebug flag for QA on machines with a working mic.