A copy button's click handler does `const text = await fetch('/doc').then(r => r.text())` and then calls `navigator.clipboard.writeText(text)`, and the write rejects with a NotAllowedError even though the user definitely clicked. What browser rule causes this, and how do you restructure the handler?

## The rule Several browser capabilities are abusable if a script can invoke them whenever it likes: writing the clipboard, opening a popup, going fullscreen, and in some browsers raising a notification permission prompt. Rather than a stored permission, these are gated on **user activation** — evidence that the current invocation traces back to a real user gesture. HTML defines two flavours, and confusing them is the root of this bug. - **Sticky activation** — the user has interacted with the document at least once since it loaded. It never expires. It gates things that only need "this is not a drive-by page", such as autoplaying audio. - **Transient activation** — the user interacted *recently*. It has a lifetime measured in seconds (Chromium and Firefox use roughly five), and certain APIs **consume** it, clearing it even before the timer runs out. The gated clipboard write needs transient activation. A click sets the flag; the handler then awaits a network round trip; the promise resolution runs in a later task, potentially seconds afterwards, and by then the flag may be gone. The call looks exactly like one made from a timer, which is the case the rule exists to block, so it rejects with `NotAllowedError`. ## Why an await is the trigger Nothing about `await` is special to the browser — it is that the code after it runs in a *later* task, after the promise settles. The same failure appears with `setTimeout`, with a promise chained onto an unrelated pending operation, or with a callback fired by a `MutationObserver`. Any hop that puts real time between the gesture and the gated call risks it. Conversely, work that completes synchronously, or in a microtask within the same turn, is normally still inside the window. The consequence is that the failure is *timing-dependent*, which is why it so often ships. On a fast local network the fetch settles in 20 ms and the copy works; on a slow connection, or on a cold cache behind a slow origin, it exceeds the window and users report "copy does nothing". Engines and versions differ slightly in strictness — WebKit is notably tighter about clipboard writes than Chromium — so "works in my browser" proves little. ## Restructuring the handler **Have the data ready.** The most reliable shape is to make the gated call synchronously with data already in memory: ```js let doc = null; button.addEventListener('pointerenter', async () => { doc ??= await fetch('/doc').then((r) => r.text()); }); button.addEventListener('click', () => { if (doc) navigator.clipboard.writeText(doc); }); ``` **Hand the API a promise.** The Clipboard API's `ClipboardItem` constructor accepts a promise for each format's data, which exists precisely so the write can be initiated inside the gesture while the bytes are still loading. WebKit has supported this pattern longest; support elsewhere has improved, so feature-detect `window.ClipboardItem` before relying on it: ```js button.addEventListener('click', () => { const blob = fetch('/doc') .then((r) => r.text()) .then((t) => new Blob([t], { type: 'text/plain' })); navigator.clipboard.write([new ClipboardItem({ 'text/plain': blob })]); }); ``` **Reorder.** If the handler must both call a gated API and do slow work, do the gated call first and the slow work after. **Do not** try to defeat the rule by re-dispatching a synthetic click. Events created by script have `isTrusted === false` and grant no activation; that is the whole design. ## Checking the flag Chromium-based browsers expose `navigator.userActivation` with two booleans — `isActive` for transient and `hasBeenActive` for sticky — which is useful for logging why a gated call failed. Support is not universal, so feature-detect and never make it load-bearing: ```js if (navigator.userActivation && !navigator.userActivation.isActive) { console.warn('activation expired before the gated call'); } ``` ## The consumption half Expiry is only one way to lose activation; some APIs spend it. `window.open()` consumes transient activation, so two calls in one click handler yield one popup and one block — the second call has nothing left to spend. Understanding consumption explains a family of "only the first one works" bugs that no amount of timing analysis would reveal. ## Which APIs are gated The set is not fixed and grows over time, but the recognisable members include clipboard reads and writes, `Element.requestFullscreen()`, `window.open()` when the popup blocker is active, and — in Firefox and Safari — `Notification.requestPermission()`. When you meet a new API that fails only from timers, transient activation is the first hypothesis to test.