@Moin、特定してくれてありがとう。修正をプッシュしました。
「いいね！」 6
ブラウザのコンソールにエラーは表示されていますか？
他のトピックでもこの問題について言及しました。
「いいね！」 1
PRはマージされました。キーガンさん、ありがとうございました！
「いいね！」 3
このコンポーネントのユーザーは、最近このエラーが多く発生していますか？
インストールしたばかりですが、アイデアがあります。
複数の投稿のコピーボタンをクリックして、クリップボードに「蓄積」します。そうすれば、スレッド全体の一部を選択的にすばやくコピーできます。
5つの投稿があると仮定します。
投稿 A
投稿 B
投稿 C
投稿 D
投稿 E
Dをコピーし、次にBをコピーし、次にEをコピーします。クリップボードにあるのは実際には次のとおりです。
B
D
E
したがって、クリップボードはコピーした順序ではなく、会話内の時系列に基づいて配置されます。
こちらでエラーが発生しましたが、クライアント側の JS エラーであるため、\logs には記録されていません。私の Discourse バージョンは 2026.7.0-latest +188 です。
私が最初に問題を発見した時点のDiscourseの正確なリビジョンと、現在のmainブランチに対して、さらに調査を行いました。
再構築した7月の環境設定において、クリップボード関連の失敗を再現することができました。Copy Post機能は、クリップボードの内容が実際に置き換えられていないにもかかわらず、成功（チェック）の表示を出すことがありました。この根本的なエラーが、私が7月に撮影したスクリーンショットに表示されていたテーマ/コンポーネントのエラーと同一であったことは確認できません。
しかし、現在の私の本番環境インスタンスでは、同じCopy Postの実装が正常に動作しています。iOS SafariのPWAを含む環境でも同様です。
7月のDiscourseリビジョンと現在のmainの間で関連するコードを比較しました。Copy Postのクリップボード実装自体に変更はなく、以下の部分に関連する変更を見つけることができませんでした：
clipboardCopy/clipboardCopyAsyncDButtonのアクションディスパッチ（iOSパスを含む）- レガシーな
DButtonシム - ポストメニューのトランスフォーマーパス
discourse/lib/ajaxのGETパス
また、生ポストのリクエストを一時停止し、リクエストが完了する前にnavigator.clipboard.write()が開始されているかをチェックする実験的なシステム仕様テストを作成しました。Copy PostをclipboardCopyAsyncに変更した場合、このテストは合格しますが、現在の実装に対しては失敗します。
しかし、私がテストしたブラウザ/デバイス（iOS Safari PWAを含む）では、現在のCopy Postが正常に動作しているため、このテストは現在のユーザーに見える回帰を示すものではなく、より強い実装制約を強制しているように見えます。
そのため、現在、このテストやclipboardCopyAsyncへの変更を修正として提案していません。過去の失敗は、Copy Postコンポーネント自体の変更ではなく、ブラウザ/WebKitの動作に依存していた可能性があります。
「いいね！」 1
この件について続報です。クリップボードへの書き込みが正常に完了した場合のみ、成功/チェックの表示がされるように変更する小さなPRを開きました。リグレッション用のシステム仕様も含まれています：
GitHub Actionsのワークフローは、CIジョブを実行する前にメンテナーの承認を待っています。
「いいね！」 1