Two conditions are checked at the moment the call executes, and neither is latched when the user clicks: the document has focus at that tick, and the user gesture is still active [4]. That is the whole mechanism. Putting `await fetch(...)` in front of the write moves the call site from "inside the click" to "whenever the network came back" [5]. The write is not queued behind the focus check and there is no warning or retry; instead the browser rejects the returned promise with `NotAllowedError` [6]. In Chrome the rejection carries `Failed to execute 'writeText' on 'Clipboard': Document is not focused.` [7]. If nothing in the code reads that rejection, it becomes an unhandled-rejection line in a log nobody watches for production [8].
The mechanism also eats the three fixes people reach for first. A spinner makes the user wait before clicking, but the failure happens after the click, while the code is still awaiting [9]. A `try/catch` around the write leaves the failure rate identical and deletes the only evidence [10]. A retry runs the same check against the same unfocused document, and a retry loop is a poller for a permission that has nothing to do with elapsed time [11].
This is a sequencing problem. There are two orderings that hold: either you already have the string when the handler runs, so `writeText()` executes in the click's own tick, or you hand the clipboard a promise. `writeText()` only accepts a string you have in hand, but `navigator.clipboard.write()` takes a `ClipboardItem` whose data may be a promise that resolves later [12]. Call `write()` synchronously in the handler and the permission check passes at the one moment it is guaranteed to be true; the browser holds the slot open and fills it when the promise settles [13]. Either way, read the returned promise and put the failure somewhere a human sees it, because the silent path is what made this unreproducible in the first place [8].
The unreproducibility has a direct cause. The failure needs focus to be lost inside the await window, so a tester clicking with the tab focused cannot produce it, no matter how many times [15]. Forty consecutive successful clicks is the expected result of testing it wrong [2]. The bug only fires when the tab has lost focus while the write is still pending, which is exactly the moment nobody is watching.
Which ordering I would pick depends on what the fetch mints. Prefetching is the cheaper option in most cases, since it needs no capability check and moves the failure into the fetch, which you already monitor. But the button in this scenario fetches a single-use link [1], and prefetching on mount or hover means minting links that nobody pastes. For that shape, the promise-valued `ClipboardItem` is the correct tool rather than the clever one. The article does not publish an engine support matrix for it [16], and that is the one thing I would confirm before shipping it.
