PowerToys Fixes What's New Contrast Bug When Its Theme Differs From Windows

It's a cosmetic fix, but it exposes an interesting chain of regressions and workarounds.

What the bug looks like​

The clearest reproduction is Windows set to Dark, PowerToys set to Light. In that setup, the What's New window's minimize, maximize and close glyphs were close to white on a light title bar. Inline-code snippets in the release notes (the PR's examples are DockSettings, settings.json, G and Win) were also nearly white text on a pale background.

The author captured the "before" state on an installed build, v0.102.2911.0. The "after" state came from a locally built x64 Debug Settings app.

One trap in the screenshots: the release notes shown inside the window are labeled v0.99.1, from April 2026. That is just the content being displayed. It is not the version of the PowerToys executable, and it is not the affected or fixed version.

Two bugs with different histories​

The PR says there are two separate causes.

• Caption buttons (a regression): The title-bar glyphs followed Windows' default app mode instead of the theme Settings applied to its own content.
• Markdown code (a long-standing gap): The code styling was never themed correctly. The PR says the source inspected at v0.99.1 already had this problem.

How the caption regression happened​

The PR's investigation timeline runs as follows:

PR #48910 itself explained the original problem. The What's New window uses the built-in WinUI title bar, which doesn't tint the system caption buttons to match the app theme. The author of #51431 also notes that an inline review comment, posted about two minutes after #49786 merged, had already warned that UseDefaultAppMode doesn't follow RequestedTheme. It recommended tracking ActualTheme. The PR says the consolidation was intentional but that its history doesn't show an intent to drop PowerToys' independent theme preference.

The release containment is based on source and tag inspection. The PR says it is not a runtime bisect of every installer.

The fix, in practical terms​

Caption buttons​

• A new explicit-theme overload is added to TitleBarHelper.cs. The original one-argument method keeps its Windows-default behavior and its supported-platform guard.
• ScoobeWindow.xaml.cs applies the initial content theme after InitializeComponent. It then sets the native title-bar theme to Light or Dark from the root element's resolved ActualTheme.
• The window tracks ActualThemeChanged live and unsubscribes when it closes.

Native caption rendering and the shared helper stay in place. The PR does not go back to hand-painting caption-button colors. Other windows keep the old behavior, and the change deliberately does not extend to OOBE or Shortcut Conflict.

Markdown code​

The release notes use a pinned CommunityToolkit Markdown control. It captures brushes from application-level resources, which follow the OS theme, instead of the theme chosen for the element. PowerToys already worked around this for headings and links. Now it does the same for code:

• Code-surface brushes are resolved through a collapsed, noninteractive, theme-aware provider, following the existing link-provider pattern.
• The element-themed primary foreground and the code background and border are applied to both inline-code and fenced-code properties.
• Heading and link handling and the re-render on theme change are kept.
• No hardcoded palette and no dependency upgrade are added.

The workaround still points to the pending upstream fix, CommunityToolkit/Labs-Windows#785. Once that lands, this local code should be removable. That's the usual lifecycle of this kind of patch.

What was tested, and what wasn't​

The PR is more candid about its limits than most.

Reported as done:

• The x64 Debug build succeeded, including the runner and Settings, with zero MSBuild errors or warnings on the main-based branch.
• ScoobeReleaseTests plus ViewModelTests.General passed: 18 passed, 0 failed.
• With Windows Dark, the author cycled PowerToys through Light, Dark, Windows default and back to Light. Caption glyphs, headings, links and the inline-code examples stayed readable.
• No installed PowerToys binaries were replaced.

Explicitly not verified:

• Windows Light combined with PowerToys Dark.
• High-contrast transitions.
• Caption hover, inactive and maximized states.
• Real fenced-code rendering. The properties compile and the implementation was inspected, but no fenced-code sample was found in the inspected notes.

The PR also adds a PowerShell capture script, Test-WhatsNewTheme.ps1. It switches themes, saves screenshots and a JSON receipt, and restores your original setting. It needs an explicit Settings process ID, uses English UI labels and the winapp CLI, and defaults to the checkout's x64 Debug build. The PR says a successful capture is not a visual pass, so a human still has to look at the images. An automated review comment on the PR also flagged open reliability concerns with the script. One was about refocusing General before each theme selection. That is a contributor-tooling matter, not something end users will see.

What it means for users​

If you run Windows in Dark and PowerToys in Light, or the reverse, the symptom is easy to spot. Open What's New and check whether the window buttons and code snippets are legible. If you keep both on the same theme, you probably never saw the problem.

I would not assume this fix is in a particular public installer. The evidence confirms the merge to main and the tag page. It doesn't establish which stable download contains it. For context, other coverage described the 0.102 line as being built from the stable branch. WindowsForum and NT Compatible reported that v0.102.2803.0 was the first member of the 0.102 release train built on the stable branch. The PR itself says the production files were ported onto current main to avoid unrelated stable-branch history. That fits a cherry-picked fix, and the release page notes a cherry-pick. Check the release notes of whichever build you install before assuming the fix is there.

A neat fix that shows how fragile theme handling is: Windows has one app-mode setting, WinUI has per-element themes, and third-party controls sometimes read from the wrong place. The result is a window that's half dark and half light.

Bottom line​

• PR #51431 fixes unreadable caption buttons and inline-code text in PowerToys' What's New window when its theme differs from Windows' app mode.
• The caption problem is a regression from the September shared-helper consolidation. The code-contrast problem predates it.
• The fix keeps native title-bar rendering and adds no new settings, strings or dependencies.
• Testing covered the reported Windows Dark and PowerToys Light case, and the PR openly lists the gaps: Windows Light with PowerToys Dark, high contrast, other caption states and fenced code.