Camera and Microphone Capture and Track Cleanup

Working case

An operator selects Capture evidence for case 47 and sees a camera preview with Capture, Retake, and Cancel. On Capture, the app freezes an image for review and stops the live video track. On Retake, it starts a new capture attempt only when needed. On Cancel, route change, or a failed upload, it also stops all active tracks and removes any temporary object URL. A file-upload path remains visible for a device without camera access. The operator can inspect the chosen image before it leaves the tablet.

Implementation boundary

Keep one owner for the current stream so lifecycle events cannot create competing captures. Once a stream resolves, check whether the screen is still active; a user may have navigated away while the browser prompt waited. If it is stale, stop the tracks immediately. Attach cleanup to cancel, unmount, successful capture, and error transitions. If switching cameras, stop old tracks before or after the replacement becomes ready according to the product’s continuity requirement. The captured file is untrusted input: enforce type, size, content inspection, and authorization on the server.

function stopCapture(stream) {
  for (const mediaTrack of stream.getTracks()) mediaTrack.stop();
  return stream.getTracks().every(mediaTrack => mediaTrack.readyState === "ended");
}
const mediaTracks = [{ readyState: "live", stop() { this.readyState = "ended"; } }];
console.log(stopCapture({ getTracks: () => mediaTracks }));
// Output: true

Cost and tradeoffs

Stopping k tracks is O(k), usually a tiny count, but the device consumes power and may hold exclusive access while tracks remain active. Encoding a large image can use memory proportional to its pixel count and can block the main thread if handled poorly. Avoid keeping full-resolution previews and duplicate blobs longer than necessary. Measure preview startup, cancellation latency, memory after repeated retakes, and upload failure recovery. A camera-specific path should not make the case form depend on a live stream after an image has already been captured.

Failure trace

A capture component unmounts after route navigation, yet a late permission approval resolves and leaves the camera indicator on. Guard the resolution with a current-screen flag and stop the returned stream when stale. Another failure stops only the first video track while an accidentally requested audio track continues. Iterate every track. Repeat capture, retake, cancel, and route change fifty times in a test session and inspect device indicators and memory. Deny access at the browser and operating-system levels and verify that the file path remains usable.

Decision note

Capture the minimum medium needed, release it at every terminal transition, and treat uploaded bytes as untrusted even if the browser produced them. A preview is a user interface state; authorization, storage limits, and scanning remain server responsibilities.

Verification

• Complete the primary case with the capability available and with it denied or absent.
• Interrupt the interaction during its pending state and confirm no stale resource, focus, or scroll state remains.
• Check that server authorization and validation still hold after the browser interaction.

Common Mistakes

• Removing a preview without stopping tracks.
• Requesting microphone access for a photo-only task.
• Trusting browser-generated media without server validation.

Connected lessons

Browser Capabilities and Permission Lifecycle; Permission Request Timing and Manual Fallback; Geolocation Accuracy, Cancellation, and Retention; Clipboard and Share Activation Fallbacks; Offline and Device Capabilities; Browser Security and Data Stewardship; Browser storage: save convenience data without storing credentials.

Apply and check

Build Project: field intake with capability fallbacks and review Web Development: browser capability and viewport decisions quiz.