感谢您指出这一点，@Moin。我已经推送了一个修复程序：
6 个赞
您在浏览器的控制台中看到任何错误吗？
我在其他主题中提到了这个问题。
1 个赞
PR 已合并；谢谢你，Keegan！
3 个赞
最近使用此组件的用户是否更多地遇到了此错误？
刚安装了它，这里有个想法：
点击多个帖子的复制按钮来“构建”你的剪贴板。这样你就可以快速选择性地复制整个帖子的一个部分。
假设有五个帖子：
帖子 A
帖子 B
帖子 C
帖子 D
帖子 E
你复制了 D，然后是 B，然后是 E。你剪贴板里的内容实际上是：
B
D
E
所以剪贴板是根据它们在对话中的时间顺序排列的，而不是你复制它们的顺序。
我在此处遇到了一个错误，由于这是一个客户端 JavaScript 错误，我无法在 \logs 中找到它。我的 Discourse 版本是 2026.7.0-latest +188
我针对最初发现问题时的确切 Discourse 版本以及当前的 main 分支进行了进一步的调查。
在一个重构的历史性七月环境中，我成功复现了一个与剪贴板相关的故障：“复制帖子”（Copy Post）功能可能会显示成功/对勾指示，但剪贴板中的内容实际上并未被替换。我无法确认这是否与我在七月截图中显示的主题/组件错误属于同一根本原因。
然而，当前的"复制帖子"实现在我目前的生产环境中运行正常，包括在 iOS Safari PWA 中也是如此。
我比较了七月 Discourse 版本和当前 main 分支之间的相关代码。"复制帖子"的剪贴板实现本身并未改变，我也未能发现以下方面的相关变更：
clipboardCopy/clipboardCopyAsyncDButton操作分发，包括 iOS 路径- 旧版
DButton垫片（shim） - 帖子菜单转换器路径
discourse/lib/ajax中的 GET 路径
我还编写了一个实验性的系统规范（system spec），该规范会暂停原始帖子请求，并检查在请求完成之前 navigator.clipboard.write() 是否已经开始。如果将"复制帖子"修改为使用 clipboardCopyAsync，该测试将通过；而针对当前实现，该测试会失败。
然而，当前的"复制帖子"功能在我测试过的浏览器/设备上均能正常工作，包括 iOS Safari PWA，因此该测试似乎是在强制执行一种更强的实现约束，而不是证明存在当前的用户可见回归问题。
因此，我目前并未提议将该测试或 clipboardCopyAsync 的变更作为修复方案。历史上的故障可能取决于浏览器/WebKit 的行为，而非"复制帖子"组件本身的变更。
1 个赞
在此基础上，我提交了一个小型 PR，修改了成功/检查指示的显示逻辑，使其仅在剪贴板写入成功完成后才显示，并附带了一个回归系统测试规范：
目前，GitHub Actions 工作流正在等待维护者批准，之后才能运行 CI 任务。
1 个赞