#257 Improve camera and microphone permission recovery

[Anonymous]

Originally created by: kristofferR

Problem

Carrier currently catches some media-capture failures, but recovery is incomplete:

• a combined microphone/camera failure can be described as only a camera problem
• denial guidance is transient
• macOS settings may open before the user explicitly asks
• Windows and Linux do not get equivalent recovery guidance
• missing hardware and denied permission are not clearly distinguished

This makes Messenger calling failures harder to diagnose than they need to be.

Goal

Provide accurate, persistent, and platform-appropriate recovery when Messenger cannot access the microphone or camera.

Design

• Distinguish permission denial from unavailable hardware and other capture failures.
• Describe microphone, camera, or both based on the devices actually requested.
• Show a persistent, accessible recovery banner after an actual denial.
• Open operating-system privacy settings only from an explicit user action.
• Add narrowly scoped native helpers for supported macOS and Windows privacy pages.
• Provide clear manual guidance on Linux where desktop-specific deep links are unreliable.
• Clear the recovery state after a successful capture or an explicit dismissal.
• Preserve the existing live-track accounting and protections against interrupting active calls.
• Do not expose arbitrary URI or command execution through the remote Messenger page.

Verification

• Unit-test error classification and device-label generation.
• Verify denial, missing-device, dismissal, and later-success flows.
• Manually test microphone-only, camera-only, and combined requests on macOS, Windows, and Linux.
• Confirm no privacy-settings page opens without an explicit click.

[Anonymous]

Originally posted by: kristofferR

[!NOTE]
🤖 GPT-6 responding on behalf of Kristoffer

Implemented in [#275], merged as ffb74e7.

The compact recovery card shows separate camera and microphone rows, distinguishes denied access from missing or unavailable hardware, and preserves independent failures until the affected devices recover. macOS has native permission status, explicit permission requests, and a recheck on return from Settings. Privacy settings open only from a user action through scoped native helpers; Windows and Linux report unavailable OS status honestly, with Linux manual guidance.

Validation: 484 Bun tests and 255 Rust tests pass. CI passed, including macOS and Windows checks; the local macOS compile check also passed. Live native permission prompts, settings launches, and cross-platform call recovery still need hands-on verification. Those unchecked items are now recorded in [#28].

Closing the implementation issue; [#28] retains the remaining verification work.

[Anonymous]

Ticket changed by: kristofferR

• status: open --> closed