Permission Request Timing and Manual Fallback

Working case

A field operator opens a case form on a shared tablet. The screen needs neither location nor camera until the operator selects Add place or Attach photo. Asking for both on page load would interrupt work and make the purpose unclear. If location is denied, the form accepts a typed district and landmark. If camera access fails, it accepts a file chosen through a normal input. The case can still be saved with an explicit Missing media status. A dismissed prompt leaves the action available for a later attempt.

Implementation boundary

Separate feature detection, permission request, result handling, and cleanup. Do not assume a Permissions API query supports every capability or that a granted query state guarantees that the device is usable. A camera may be unplugged; an operating-system privacy setting may still block it. Catch request errors and map them to human actions rather than exposing only an exception name. Keep an in-progress state while a prompt is open, but do not spin forever: provide a cancel path that restores the form. The server validates every uploaded file and submitted location regardless of the browser path used.

function captureChoice(capabilityAvailable, permissionResult) {
  if (!capabilityAvailable || permissionResult !== "granted") return "manual-entry";
  return "device-entry";
}
console.log(captureChoice(true, "denied"));
// Output: manual-entry

Cost and tradeoffs

Checking an in-memory capability flag is O(1); the real cost lies in user interruption, device startup, network uploads, and any background sensor work. Permission prompts are especially expensive when they appear before the person understands the benefit. A manual fallback adds interface and validation work but prevents a denied permission from blocking the whole task. Measure completion rate and time-to-complete for allowed, denied, dismissed, and unsupported paths. Do not count a granted prompt as a successful case submission.

Failure trace

A dashboard automatically asks for location on every visit. Operators who need only to read cases deny it, and the product then incorrectly disables the form. Move the request behind Add place, keep manual address entry, and test the four permission outcomes. Suspend the tab while the prompt is open, return later, and verify that buttons are neither duplicated nor stuck disabled. Test the same workflow with browser permissions pre-denied and with the relevant API removed. Confirm that every route still produces a valid server request.

Decision note

Request only the capability needed for the chosen action. Treat denial as one expected branch of the workflow, with a useful manual result and a clear retry path. The interface may explain why access helps, but it must not promise that the browser will display a particular prompt or remember a decision for a fixed duration.

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

• Requesting every device permission when the page opens.
• Assuming a permission-state query guarantees usable hardware.
• Disabling the full form after a denied optional capability.

Connected lessons

Browser Capabilities and Permission Lifecycle; Camera and Microphone Capture and Track Cleanup; Geolocation Accuracy, Cancellation, and Retention; Clipboard and Share Activation Fallbacks; Offline and Device Capabilities; Browser Security and Data Stewardship; Responsive interaction: preserve content and control order.

Apply and check

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

Further connections

Notification Opt-In and Channel Preference.

Further connections

Media Capture Consent and Track Lifecycle.