Clipboard and native-share features are optional browser capabilities. A copy or share call may require a secure context, a recent user gesture, and browser-specific permission conditions. It can reject even when a method exists. The interface should preserve the material the person wanted to move: a visible, selectable case identifier or a normal review link remains useful after failure. Never read clipboard contents automatically simply to make a copy button look convenient. That crosses a separate privacy boundary and often has different permission rules.
Clipboard and Share Activation Fallbacks
Working case
A reviewer opens case 47 and selects Copy case ID. The button initiates a write from the click handler and announces Copied only after the promise resolves. If the write rejects, the identifier stays visible in a selectable field with instructions to copy manually. The adjacent Share review action attempts the operating system’s share sheet only when available and requested. A dismissed share sheet leaves the page intact. A normal internal review link remains present for copying without requiring a native share target.
Implementation boundary
Feature-detect each method immediately before use and keep calls tied to the originating activation when required. Do not await unrelated network requests before invoking a gated API. Catch rejection and distinguish cancellation from a product error when the platform exposes that distinction reliably. For a share payload, use a stable URL that the recipient can actually authorize; a private case link is not a public grant. Do not embed raw case notes into a share title or copied URL. The server still checks access when the link is opened.
function copyStatus(result) {
return result === "resolved" ? "copied" : "select-and-copy";
}
console.log(copyStatus("rejected"));
// Output: select-and-copyCost and tradeoffs
Copying a short identifier is O(n) in the number of characters transferred and has negligible compute cost. The main cost is behavioral: false success messages make users paste stale clipboard content, and hidden fallback text makes failure hard to recover from. Native sharing can improve handoff on mobile but its available targets and result semantics differ by platform. Test not only that an API call resolves, but that a human can complete the handoff after rejection or cancellation. Avoid logging the copied private payload.
Failure trace
A handler awaits a case refresh before calling share, so the browser no longer recognizes the original user activation and rejects the request. Prepare the safe share payload before the click or invoke the capability directly from the click path. Another defect changes the label to Copied before the write promise settles. Wait for success. Test unsupported APIs, rejected writes, a dismissed share sheet, account changes, and a recipient without case access. The recipient should reach an access decision, not a leaked private record.
Decision note
A browser convenience action should be an enhancement to visible, usable content. Confirm completion only after the capability succeeds, and keep server authorization on anything the copied or shared value points to.
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
- Showing success before the clipboard write resolves.
- Waiting through another async operation before a user-activated share call.
- Treating a shared private link as permission to read its target.
Connected lessons
Browser Capabilities and Permission Lifecycle; Permission Request Timing and Manual Fallback; Camera and Microphone Capture and Track Cleanup; Geolocation Accuracy, Cancellation, and Retention; Browser Security and Data Stewardship; Identity and Application Security; 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.
