Build an intake form for a field case numbered 47. The operator can capture a photo, choose a file, add an approximate place, type that place manually, copy a case identifier, and share a review link. None of those browser capabilities may be requested on initial page load. Each request follows an explicit button action, has a pending and rejected state, and leaves a useful manual path. The photo preview must stop every live media track after capture or cancellation. A late camera permission approval after route leave must also release its stream. Location data has an accuracy and age policy, and the form never presents a wide-radius estimate as an exact address. The submitted file and location still pass server-side validation and authorization. A private review link must not grant access merely because it was shared.
Project: field intake with capability fallbacks
Build contract
- Test allowed, denied, dismissed, unsupported, and operating-system-blocked capability paths.
- Cancel or leave during a pending camera request, then inspect every track and object URL after resolution.
- Compare recent and stale location readings; preserve manual place entry and approved retention scope.
- Reject clipboard and share calls deliberately and verify usable selectable content and access-controlled links.
Implementation checkpoint
function intakePath(cameraAllowed, locationAllowed) {
return { media: cameraAllowed ? "capture" : "file-picker", place: locationAllowed ? "review-estimate" : "manual-place" };
}
console.log(JSON.stringify(intakePath(false, true)));
// Output: {"media":"file-picker","place":"review-estimate"}Cost and boundaries
The capability check itself is O(1); media decoding uses space related to image size, and a live camera or location watch uses device resources until released. Avoid keeping multiple full-resolution copies of each preview. Measure task completion and recovery time for each rejected path, not just the fraction of granted prompts. Server checks add work proportional to the bytes and fields submitted; that cost is required because a browser-generated file is still untrusted. A manual path adds a small interface burden but allows the work to finish without device access.
Failure drill
Request all capabilities when the form mounts; the test should flag that behavior immediately. Grant camera permission after leaving the route and check that no track remains active. Deny location and confirm the place field still saves. Return a position with a wide accuracy radius and confirm the operator must review it. Reject clipboard write and confirm the UI never says Copied; the identifier remains selectable. Share a link to another account and verify that opening it triggers a normal server access decision. Force an upload rejection and check that temporary media and pending states are cleaned up.
Acceptance checks
- No optional capability is requested before its named user action.
- Every media track and temporary preview is released after terminal transitions.
- Denied and unsupported branches still permit a valid case submission.
- Shared or copied identifiers do not bypass server authorization.
Common Mistakes
- Using permission grant as proof that capture or upload succeeded.
- Leaving a camera stream open after a canceled form.
- Treating approximate coordinates as a verified address.
- Showing clipboard success before the write resolves.
Related lessons
Permission Request Timing and Manual Fallback; Camera and Microphone Capture and Track Cleanup; Geolocation Accuracy, Cancellation, and Retention; Clipboard and Share Activation Fallbacks.