Versão do Discourse
2026.1.0-latest (c7e9cddb06)
Navegador
Chrome 143.0.7499.170 (Build Oficial) 64-bit
(cohort: 144.0.7559.59 rollout)
SO
Windows 11 Home
Versão 10.0.26200 (Build 26200)
Resumo
Quando a aceleração de hardware do Chrome está ativada, ocorre um problema de UI:
O cursor de texto no composer fica invisível (aparece branco sobre um fundo branco).
quando os blocos de eventos do Discourse Calendar foram cozidos (rendered)
O problema desaparece imediatamente quando a aceleração de hardware é desativada no Chrome.
Isso sugere um problema de renderização da GPU/compositor do Chrome interagindo com os elementos da UI do Discourse, em vez de uma regressão puramente CSS.
Problemas observados
Cursor do composer fica invisível
- Ocorre tanto no composer de novo tópico quanto no de resposta.
- O cursor aparece branco / se mistura com o fundo, dificultando ou impossibilitando a visualização da posição de digitação.
- Ocorre intermitentemente, mas de forma reproduzível com a aceleração de hardware ativada.
Comportamento notável:
- Abrir o Chrome DevTools faz com que o cursor volte a ser renderizado normalmente imediatamente.
- Isso sugere fortemente um recálculo de renderização/composição, em vez de mudanças de estado ou CSS.
Blocos de eventos do discourse-calendar não são exibidos corretamente (onebox) no modo seguro
Quando a aceleração de hardware está ativada:
- No
/safe-mode, esse comportamento muda (esperado, já que os componentes de tema estão desativados).
Reprodução
- Use o Chrome no Windows 11 com “Usar aceleração gráfica quando disponível” ativado
- Abra um site Discourse rodando
2026.1.0-latest - Abra o composer e comece a digitar
- Observe o cursor invisível/branco
- Insira ou visualize blocos de eventos do discourse-calendar
Não reprodução / diagnósticos
Não é possível reproduzir no /safe-mode
Ainda reproduz no modo anônimo (não relacionado a extensões)
Nenhum CSS personalizado configurado
Abrir o Chrome DevTools corrige imediatamente o problema do cursor
Desativar a aceleração de hardware do Chrome resolve completamente ambos os problemas
Caminho:
Chrome → Configurações → Sistema →
[ ] Usar aceleração gráfica quando disponível
Após desativar:
- O cursor é renderizado normalmente
- Os oneboxes de eventos se comportam corretamente
- O problema não pode ser reproduzido
Notas / hipótese
Isto parece ser um problema de interação da GPU/compositor do Chrome, potencialmente envolvendo:
- Renderização do cursor em campos de texto / ProseMirror
- Tempo de repintura ou camadas de foco
- Renderização/cálculo de layout do onebox sob composição acelerada
O fato de que:
- o modo seguro altera o comportamento,
- abrir o DevTools aciona a correção imediata,
- e a aceleração da GPU controla totalmente a reprodutibilidade
sugere fortemente um problema de renderização no nível do navegador, em vez de uma regressão do Discourse introduzida por commits recentes.
Abordagens de depuração sugeridas
Como abrir o DevTools altera o comportamento de renderização, pode ser útil:
- inspecionar usando DevTools remoto em vez de DevTools local
- testar com o DevTools aberto desde o carregamento inicial da página
- comparar o comportamento com
--disable-gpu - revisar a saída de
chrome://gpuem sistemas afetados
Elementos chave para inspecionar quando o problema está ativo:
- Elementos do Composer:
textarea.d-editor-input.d-editor .ProseMirror
- Renderização computada do cursor (
caret-color, camadas de composição) - Tempo de repintura do contêiner do Onebox
Solução alternativa (Workaround)
Para usuários afetados no Windows 11:
Desative a aceleração de hardware do Chrome
Isso resolve completamente tanto o problema do cursor do composer quanto o comportamento de oneboxing do discourse-calendar.