Obrigado por identificar isso, @Moin. Empurrei uma correção:
Você vê algum erro no console do navegador?
Mencionei este problema no outro tópico.
O PR foi mesclado; obrigado, Keegan!
Os usuários deste componente têm tido este erro mais recentemente?
Acabei de instalar, aqui está uma ideia:
Clique no botão de copiar em várias postagens para “construir” sua área de transferência. Dessa forma, você pode copiar rapidamente uma seção inteira de um tópico seletivamente.
Digamos que existam cinco postagens:
Postagem A
Postagem B
Postagem C
Postagem D
Postagem E
Você copia D, depois B, depois E. O que está na sua área de transferência é, na verdade:
B
D
E
Então, a área de transferência é organizada com base na cronologia delas na conversa, e não na ordem em que você as copia.
tive um erro nisso e, como é um erro de JS no lado do cliente, não consigo encontrá-lo em \logs. Minha versão do Discourse é 2026.7.0-latest +188
Investiguei isso com mais profundidade, comparando a revisão exata do Discourse da época em que vi o problema pela primeira vez com a main atual.
Em uma configuração histórica de julho reconstruída, consegui reproduzir uma falha relacionada à área de transferência: o “Copiar publicação” podia exibir a indicação de sucesso/check, enquanto o conteúdo da área de transferência não era efetivamente substituído. Não posso confirmar se esse era o mesmo erro subjacente ao erro de tema/componente mostrado na minha captura de tela original de julho.
No entanto, a mesma implementação de “Copiar publicação” agora funciona na minha instância de produção atual, incluindo em um PWA do Safari para iOS.
Comparei o código relevante entre a revisão do Discourse de julho e a main atual. A própria implementação da área de transferência do “Copiar publicação” não mudou, e não encontrei nenhuma alteração relevante em:
clipboardCopy/clipboardCopyAsync- despacho de ação do
DButton, incluindo o caminho para iOS - o shim legado do
DButton - o caminho do transformador do menu de publicação
- o caminho GET em
discourse/lib/ajax
Também escrevi uma especificação de sistema experimental que pausa a requisição de publicação bruta e verifica se navigator.clipboard.write() foi iniciado antes da conclusão da requisição. Esse teste passa se o “Copiar publicação” for alterado para usar clipboardCopyAsync e falha contra a implementação atual.
No entanto, o “Copiar publicação” atual funciona nos navegadores/dispositivos que testei, incluindo o PWA do Safari para iOS, portanto, esse teste parece impor uma restrição de implementação mais forte, em vez de demonstrar uma regressão atual visível ao usuário.
Por esse motivo, não estou propondo atualmente esse teste ou a alteração para clipboardCopyAsync como correção. A falha histórica pode ter dependido do comportamento do navegador/WebKit, em vez de uma alteração no próprio componente de “Copiar publicação”.
Em continuidade a isso, abri um pequeno PR que altera a indicação de sucesso/check para que ela só seja exibida após a escrita na área de transferência ter sido concluída com sucesso, incluindo uma especificação de sistema de regressão:
O workflow do GitHub Actions está aguardando aprovação do mantenedor antes que os jobs de CI possam ser executados.


