[Problem/Bug]: Yellow color cast in all WebView2 apps (SDR, HDR off) on HDR-capable wide-gamut displays after Runtime update to 154.0.4258.37

What happened?

Summary

After the evergreen WebView2 Runtime auto-updated to 154.0.4258.37 (2026-09-29, 18:40 local), every WebView2-based
app on this machine started rendering its web UI with a strong yellow/warm color cast whenever the display is in
SDR mode (HDR off). Non-Chromium windows are unaffected, and enabling HDR makes it neutral. The Edge browser (same
Chromium build 154.0.4258.37) shows the identical issue in web content (since 2026-09-26).

This appears to be the Chromium 154 display color-space regression already filed as
issues.chromium.org/issues/566216548. Filing here as well because the WebView2 Runtime is shipped and auto-updated
by Microsoft, so this breaks WebView2 host apps (e.g., Tauri apps) for end users with no way to pin the previous
runtime.

Environment

• Windows 11 25H2 (10.0.26200); NVIDIA RTX 5070 Laptop GPU, driver 32.0.16.1714
• WebView2 Runtime 154.0.4258.37 (evergreen); Edge 154.0.4258.37; Chrome 154.0.8037.58
• Display: TCL 27Q7A Pro, 2560×1440 @320 Hz, HDMI — HDR-capable wide-gamut (BT.2020-class) panel; EDID declares
  BT2020RGB + HDR static metadata
• HDR disabled (SDR); Auto Color Management off; hardware acceleration on

Steps to reproduce

1. Use an HDR-capable wide-gamut display in SDR mode (HDR off).
2. Launch any WebView2 app (reproduced with two Tauri apps) with default settings.
3. The web UI renders with an obvious yellow/warm cast.

Evidence

• Not ICC-related: reproduces with all display color profiles and associations removed, after a reboot, and with a
  fresh browser profile.
• edge://gpu → "Display(s) Information" reports the display color space as the panel's own primaries instead of any
  installed profile:
  {r:[0.7038, 0.2809], g:[0.1615, 0.7822], b:[0.1370, 0.0464], w:[0.3127, 0.3290]}, transfer:SRGB
  Treating these primaries as raw XYZ columns implies a white of ≈(0.334, 0.370) — warmer than D65 (0.3127, 0.3290) —
  which matches the yellow cast.
• Measured on a solid #FFFFFF page: (221, 220, 193) without any flag vs (255, 255, 255) with
  --force-color-profile=srgb.

Workarounds (verified)

• WebView2 apps: set the user environment variable WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--force-color-profile=srgb
  — fixes all WebView2 apps at once
• Or keep HDR enabled on this display
• Browsers: launch with --force-color-profile=srgb

Request: please track this from the WebView2/Edge side and coordinate with the Chromium fix for issue 566216548.

---

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

154.0.4258.37

SDK Version

N/A

Framework

Other

Operating System

Windows 11

OS Version

10.0.26200.9457

Repro steps

Environment: Windows 11 25H2 (10.0.26200.9457); NVIDIA RTX 5070 Laptop GPU, driver 32.0.16.1714; display: TCL
27Q7A Pro, 2560×1440 @320 Hz, HDMI — HDR-capable wide-gamut (BT.2020-class) panel, EDID declares BT2020RGB + HDR
static metadata; WebView2 Runtime 154.0.4258.37 (stable); HDR disabled (SDR), Auto Color Management off, hardware
acceleration on.

Steps

1. Use an HDR-capable wide-gamut display in SDR mode (HDR off).
2. Launch any WebView2 host app (reproduced with two Tauri apps). The same issue also reproduces in Edge 154 / Chrome
   154 web content.
3. Observe all web content rendered with a strong yellow/warm cast.

Expected vs actual

• Expected: a #FFFFFF page renders as neutral white.
• Actual: it renders as ≈(221, 220, 193) — obvious yellow cast. Enabling HDR, or forcing --force-color-profile=srgb,
  makes it neutral (255, 255, 255).

Additional evidence

• Not ICC-related: reproduces with all display color profiles/associations removed, after a reboot, and with a fresh
  browser profile.
• edge://gpu reports the display color space as the panel's own primaries: {r:[0.7038,0.2809], g:[0.1615,0.7822], b:[0.1370,0.0464]}.
• Same root cause filed with Chromium: issues.chromium.org/issues/566216548.

Repros in Edge Browser

Yes, issue can be reproduced in the corresponding Edge version

Regression

Regression in newer Runtime

Last working version (if regression)

Runtime 153.x (exact build not recorded; regressed with the auto-update to 154.0.4258.37 on2026-09-29)