I investigated this further against the exact Discourse revision from when I originally saw the problem, and against current main.
On a reconstructed historical July setup, I was able to reproduce a clipboard-related failure: Copy Post could show the success/check indication while the clipboard contents were not actually replaced. I cannot confirm that this was the same underlying error as the theme/component error shown in my original July screenshot.
However, the same Copy Post implementation now works on my current production instance, including in an iOS Safari PWA.
I compared the relevant code between the July Discourse revision and current main. The Copy Post clipboard implementation itself has not changed, and I could not find a relevant change in:
clipboardCopy/clipboardCopyAsyncDButtonaction dispatch, including the iOS path- the legacy
DButtonshim - the post-menu transformer path
- the GET path in
discourse/lib/ajax
I also wrote an experimental system spec which pauses the raw-post request and checks whether navigator.clipboard.write() has started before the request completes. That test passes if Copy Post is changed to use clipboardCopyAsync, and fails against the current implementation.
However, current Copy Post works in the browsers/devices I have tested, including iOS Safari PWA, so that test appears to enforce a stronger implementation constraint rather than demonstrate a current user-facing regression.
For that reason I am not currently proposing that test or the clipboardCopyAsync change as a fix. The historical failure may have depended on browser/WebKit behaviour rather than a change in the Copy Post component itself.