## Summary of the Pull Request
Fix unreadable caption-button glyphs and Markdown code in the separate
**What's New** window when the PowerToys theme differs from Windows'
default app mode.
With Windows Dark and PowerToys Light, minimize/maximize/close glyphs
and inline-code text can be almost white on a light surface. The caption
issue is a regression; the Markdown code-brush gap predates it.
This is a targeted follow-up to #48910 and #49786, **not a revert of the
shared native title-bar implementation**.
## Before / after screenshots
Both captures use **Windows Dark + PowerToys Light** and display the
same April 2026 release notes. The displayed v0.99.1 is the notes'
version, not the executable's version.
### Before: installed v0.102.2911.0
The minimize/maximize/close glyphs are almost invisible against the
light title bar. Inline-code examples such as `DockSettings`,
`settings.json`, `G`, and `Win` also have nearly white text on a pale
background.
### After: patched local x64 Debug Settings
Caption glyphs and inline-code text are readable, while the existing
heading/link styling is retained.
## PR Checklist
- **Related work:** #48910, #49786; no existing issue is closed by this
PR.
- [ ] **Communication:** Separate contributor agreement has not been
established; this follows the previously identified theme-override
concern linked below.
- [x] **Tests:** Added a repeatable UI regression-capture script;
existing focused Settings tests pass. Screenshot review remains manual,
not an automated contrast assertion.
- [x] **Localization:** No new user-facing strings.
- **Dev docs / product documentation / new binaries:** Not applicable;
no new dependencies, settings fields, IPC contracts, or installer
entries.
## Detailed Description of the Pull Request / Additional comments
### Caption buttons: follow the window, not Windows' default app mode
`TitleBarTheme.UseDefaultAppMode` follows Windows' default app mode.
Settings applies its own Light/Dark preference to the window content, so
these can disagree.
- Add an explicit-theme overload to
`src/common/Common.UI.Controls/Window/TitleBarHelper.cs`. Preserve the
original one-argument API, its Windows-default behavior, and the
supported-platform guard.
- In `src/settings-ui/Settings.UI/SettingsXAML/ScoobeWindow.xaml.cs`,
apply the initial content theme after `InitializeComponent`, then set
native `TitleBarTheme.Light`/`Dark` from the root's resolved
`ActualTheme`.
- Track live `ActualThemeChanged` events and unsubscribe when the window
closes.
This retains #49786's shared helper and native caption rendering rather
than restoring manually assigned caption-button colors. Other
windows/modules keep their existing one-argument behavior; this PR does
not broaden the change to OOBE or Shortcut Conflict.
### Markdown: extend the existing element-theme workaround to code
The pinned Markdown control captures brushes from application resources
rather than the selected element theme. The existing workaround corrects
headings and links, but not inline/fenced-code foreground, background,
or border brushes.
In `ScoobeReleaseNotesPage.xaml` / `.xaml.cs`:
- Resolve code-surface brushes through a collapsed, noninteractive,
theme-aware provider, following the existing link-provider pattern.
- Apply the element-themed primary foreground and code background/border
to both inline-code and fenced-code theme properties.
- Retain heading/link handling and the existing re-render path on theme
changes.
No hardcoded palette or dependency upgrade is introduced. The workaround
still points to the pending upstream fix,
[CommunityToolkit/Labs-Windows#785](https://github.com/CommunityToolkit/Labs-Windows/pull/785).
### Investigation timeline
| Date (UTC) | Change / inspected release | Relevance |
|---|---|---|
| April 29, 2026 | v0.99.1 | Inspected source already has the Markdown
code-brush problem; the old code-rendering issue is not explained by the
later caption regression. |
| June 29, 2026 | #48910, merged 18:33:41 | Corrected What's New
headings/links and tracked the actual window theme for caption colors.
It did not correct code brushes. |
| August 25, 2026 | v0.101.2362.0 | Contains the June caption handling,
before its September replacement. This explains correct caption icons
but unreadable code in the older comparison build. |
| September 2, 2026 | #49786, merged 14:58:31 | Adopted the shared
native `UseDefaultAppMode` helper and explicitly removed the SCOOBE
caption handling as redundant. This lost the app-specific theme
override. |
| September 21, 2026 | v0.101.2632.0 | Already contains the September
replacement: the caption regression predates the October candidate. |
| October 16 / 19, 2026 | v0.102.2883.0 / v0.102.2911.0 | Both contain
the replacement; the reported mixed-theme symptoms were reproduced on
installed 2911. |
#49786's consolidation and native theme-change fixes were intentional.
Its history does not establish an intent to drop PowerToys' independent
theme preference. An [inline discussion posted at 15:00:33 UTC, about
two minutes after
merge](https://github.com/microsoft/PowerToys/pull/49786#discussion_r3915503538),
already identifies that `UseDefaultAppMode` does not follow
`RequestedTheme` and recommends tracking `ActualTheme`.
Release containment above comes from source/tag inspection, not a
runtime bisect of every listed installer. The April version displayed
inside What's New is release-note content, not the installed
executable's version.
## Validation Steps Performed
- Built the release-targeted x64 Debug candidate with
`tools\build\build-essentials.ps1`, including runner and Settings; no
replacement of the installed PowerToys binaries.
- Built the Settings unit-test project and ran `ScoobeReleaseTests` plus
`ViewModelTests.General` with `vstest.console.exe`: **18 passed, 0
failed**.
- Visually checked the same What's New window with Windows Dark while
selecting PowerToys **Light -> Dark -> Windows default -> Light**.
Caption glyphs, headings, links, and April's inline-code examples
(`DockSettings`, `settings.json`, `G`, `Win`) remain readable.
- The reporter also inspected the patched window and confirmed it looks
correct.
- Restored the original PowerToys Light setting after the capture.
- Ported the identical four production files onto current `main`,
avoiding unrelated stable-branch history.
- Repeated `build-essentials.ps1 -Platform x64 -Configuration Debug` on
the actual main-based PR branch: solution restore, runner and Settings
all succeeded with zero MSBuild errors/warnings.
- Rebuilt the Settings test project on that branch and repeated the same
focused test run: **18 passed, 0 failed**.
The checked-in `src\settings-ui\Settings.UITests\Test-WhatsNewTheme.ps1`
repeats that live-switch capture, checks that the same notes window
survives, verifies the selected theme, restores the original app theme,
and writes PNGs plus a JSON receipt. It requires an explicitly selected
Settings PID and checks its executable identity. Run from the checkout
after opening General and a separate What's New window containing code:
```powershell
.\src\settings-ui\Settings.UITests\Test-WhatsNewTheme.ps1 -AppPid <settings-process-id>
```
The script uses English UI labels and winapp CLI. Its default executable
is the checkout's x64 Debug build; use `-ExpectedExecutable` when
deliberately comparing a different build. Review the PNGs manually; a
successful capture is **not** a visual PASS.
### Remaining manual coverage
- Windows Light + PowerToys Dark, and high-contrast transitions.
- Caption hover, inactive, and maximized states.
- Actual fenced-code rendering: the corresponding renderer properties
compile and its implementation was inspected, but no retained
fenced-code fixture was found in the fetched stable notes after
installer-hash sections were removed.
These are explicitly unverified, not claimed as passing. No full
release/module verification is claimed.
---------
(cherry picked from commit bce86ab181a62486479afca6c6f6b83125998854)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b53a83e5-69a1-4b97-a4c6-378bdf88657a
