# L'accélération matérielle de Chrome provoque l'invisibilité du caret du compositeur là où il y a une onebox discourse-calendar (Windows 11)

**URL:** <https://meta.discourse.org/t/chrome-hardware-acceleration-causes-composer-caret-invisibility-where-there-is-a-discourse-calendar-onebox-windows-11/393809>\
**Category:** General\
**Tags:** composer, events\
**Created:** [Janvier 19, 2026, 4:46 UTC](https://meta.discourse.org/t/chrome-hardware-acceleration-causes-composer-caret-invisibility-where-there-is-a-discourse-calendar-onebox-windows-11/393809 "2026-01-19T16:46:21Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\
**Post date:** [Janvier 19, 2026, 4:46 UTC](https://meta.discourse.org/t/chrome-hardware-acceleration-causes-composer-caret-invisibility-where-there-is-a-discourse-calendar-onebox-windows-11/393809/1 "2026-01-19T16:46:21Z")

</div>

**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

### 1️⃣ 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.

### 2️⃣ 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

1. Utiliser Chrome sur Windows 11 avec **« Utiliser l’accélération graphique si disponible » activé**
2. Ouvrir un site Discourse exécutant `2026.1.0-latest`
3. Ouvrir le compositeur et commencer à taper
4. Observer le curseur invisible/blanc
5. 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 :

```plaintext
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://gpu` sur 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.