Chrome hardware acceleration causes composer caret invisibility where there is a discourse-calendar onebox (Windows 11)

General
,
1

Discourse version
2026.1.0-latest (c7e9cddb06)

Browser
Chrome 143.0.7499.170 (Official Build) 64-bit
(cohort: 144.0.7559.59 rollout)

OS
Windows 11 Home
Version 10.0.26200 (Build 26200)

Summary

When Chrome hardware acceleration is enabled, UI issue occurs:

The text caret in the composer becomes invisible (appears white on a white background).
when Discourse Calendar event blocks ahve been cooked

The issue disappears immediately when hardware acceleration is disabled in Chrome.

This suggests a Chrome GPU / compositor rendering issue interacting with Discourse UI elements rather than a pure CSS regression.

Issues observed

:one: Composer caret becomes invisible

  • Occurs in both new-topic and reply composers.
  • Caret appears white / blends into background, making it difficult or impossible to see typing position.
  • Happens intermittently but reproducibly with hardware acceleration enabled.

Notable behaviour:

  • Opening Chrome DevTools immediately causes the caret to render normally again.
  • This strongly suggests a rendering/compositing recalculation rather than state or CSS changes.

:two: discourse-calendar event blocks don’t onebox in safe mode

When hardware acceleration is enabled:

  • In /safe-mode, this behaviour changes (expected, since theme components are disabled).

Reproduction

  1. Use Chrome on Windows 11 with “Use graphics acceleration when available” enabled
  2. Open a Discourse site running 2026.1.0-latest
  3. Open the composer and begin typing
  4. Observe invisible/white caret
  5. Insert or view discourse-calendar event blocks

Non-reproduction / diagnostics

  • :cross_mark: Cannot reproduce in /safe-mode
  • :cross_mark: Still reproduces in Incognito mode (not extension-related)
  • :cross_mark: No custom CSS configured
  • :white_check_mark: Opening Chrome DevTools immediately fixes the caret issue
  • :white_check_mark: Disabling Chrome hardware acceleration fully resolves both issues

Path:

Chrome → Settings → System → 
[ ] Use graphics acceleration when available

After disabling:

  • Caret renders normally
  • Event oneboxes behave correctly
  • Issue cannot be reproduced

Notes / hypothesis

This appears to be a Chrome GPU/compositor interaction issue, potentially involving:

  • caret rendering in text inputs / ProseMirror
  • repaint timing or focus layers
  • onebox rendering/layout calculation under accelerated compositing

The fact that:

  • safe mode changes behaviour,
  • DevTools opening triggers immediate correction,
  • and GPU acceleration fully controls reproducibility

strongly suggests a browser-level rendering issue rather than a Discourse regression introduced by recent commits.

Suggested debugging approaches

Because opening DevTools alters rendering behaviour, it may help to:

  • inspect using remote DevTools rather than local DevTools
  • test with DevTools open from initial page load
  • compare behaviour with --disable-gpu
  • review chrome://gpu output on affected systems

Key elements to inspect when the issue is active:

  • Composer elements:
    • textarea.d-editor-input
    • .d-editor .ProseMirror
  • Computed caret rendering (caret-color, compositing layers)
  • Onebox container repaint timing

Workaround

For affected users on Windows 11:

Disable Chrome hardware acceleration

This fully resolves both the composer caret issue and discourse-calendar oneboxing behaviour.

1 Like