Version de Discourse
2026.1.0-latest (c7e9cddb06)
Navigateur
Chrome 143.0.7499.170 (Build officielle) 64-bit
(cohorte : déploiement 144.0.7559.59)
SE
Windows 11 Home
Version 10.0.26200 (Build 26200)
Résumé
Lorsque l’accélération matérielle de Chrome est activée, un problème d’interface utilisateur se produit :
Le curseur de texte dans le compositeur devient invisible (apparaît blanc sur fond blanc).
lorsque les blocs d’événements du calendrier Discourse ont été cuits (cooked)
Le problème disparaît immédiatement lorsque l’accélération matérielle est désactivée dans Chrome.
Ceci suggère un problème de rendu GPU/compositeur de Chrome interagissant avec les éléments d’interface utilisateur de Discourse plutôt qu’une pure régression CSS.
Problèmes observés
Le curseur du compositeur devient invisible
- Se produit dans les compositeurs de nouveau sujet et de réponse.
- Le curseur apparaît blanc / se fond dans l’arrière-plan, rendant difficile, voire impossible, de voir la position de frappe.
- Se produit de manière intermittente mais reproductible avec l’accélération matérielle activée.
Comportement notable :
- L’ouverture des outils de développement Chrome fait immédiatement réapparaître le curseur normalement.
- Ceci suggère fortement un recalcul de rendu/composition plutôt que des changements d’état ou de CSS.
Les blocs d’événements discourse-calendar ne s’affichent pas en aperçu (onebox) en mode sans échec
Lorsque l’accélération matérielle est activée :
- En
/safe-mode, ce comportement change (ce qui est attendu, car les composants de thème sont désactivés).
Reproduction
- Utiliser Chrome sur Windows 11 avec « Utiliser l’accélération graphique si disponible » activé
- Ouvrir un site Discourse exécutant
2026.1.0-latest - Ouvrir le compositeur et commencer à taper
- Observer le curseur invisible/blanc
- Insérer ou visualiser des blocs d’événements discourse-calendar
Non-reproduction / diagnostics
Impossible à reproduire en /safe-mode
Se reproduit toujours en mode Incognito (non lié aux extensions)
Aucun CSS personnalisé configuré
L’ouverture des outils de développement Chrome corrige immédiatement le problème du curseur
La désactivation de l’accélération matérielle de Chrome résout entièrement les deux problèmes
Chemin :
Chrome → Paramètres → Système →
[ ] Utiliser l'accélération graphique si disponible
Après désactivation :
- Le curseur s’affiche normalement
- Les aperçus d’événements (oneboxes) se comportent correctement
- Le problème ne peut pas être reproduit
Notes / hypothèse
Il semble s’agir d’un problème d’interaction GPU/compositeur de Chrome, impliquant potentiellement :
- Le rendu du curseur dans les champs de texte / ProseMirror
- Le moment du repeint (repaint timing) ou les couches de focus
- Le rendu/calcul de mise en page des aperçus (onebox) sous composition accélérée
Le fait que :
- le mode sans échec modifie le comportement,
- l’ouverture des outils de développement déclenche une correction immédiate,
- et l’accélération GPU contrôle entièrement la reproductibilité
suggère fortement un problème de rendu au niveau du navigateur plutôt qu’une régression Discourse introduite par les derniers commits.
Approches de débogage suggérées
Étant donné que l’ouverture des outils de développement modifie le comportement de rendu, il peut être utile de :
- inspecter en utilisant les outils de développement à distance plutôt que les outils locaux
- tester avec les outils de développement ouverts dès le chargement initial de la page
- comparer le comportement avec
--disable-gpu - examiner la sortie de
chrome://gpusur les systèmes affectés
Éléments clés à inspecter lorsque le problème est actif :
- Éléments du compositeur :
textarea.d-editor-input.d-editor .ProseMirror
- Rendu calculé du curseur (
caret-color, couches de composition) - Moment du repeint du conteneur d’aperçu (onebox)
Solution de contournement
Pour les utilisateurs affectés sous Windows 11 :
Désactiver l’accélération matérielle de Chrome
Ceci résout entièrement le problème du curseur du compositeur et le comportement d’aperçu (oneboxing) de discourse-calendar.