[Windows] Fix WebView Does Not Inherit App Theme#35037
Merged
kubaflo merged 8 commits intoMay 21, 2026
Merged
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35037Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35037" |
dotnet-policy-service
Bot
added
the
partner/syncfusion
sheiksyedm
added
platform/windows
community ✨
Contributor
|
/azp run maui-pr-uitests, maui-pr-devicetests |
|
Azure Pipelines successfully started running 2 pipeline(s). |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR targets Windows WebView2 theme integration by mapping MAUI/WinUI effective theme to WebView2’s CoreWebView2.Profile.PreferredColorScheme, so prefers-color-scheme in web content aligns with the app’s theme rather than the OS theme.
Changes:
- Add a Windows
WebView2UpdateBackgroundextension to setDefaultBackgroundColorand adjustPreferredColorScheme. - Wire up
IView.Backgroundmapping for WindowsWebViewHandlerand apply it whenCoreWebView2initializes. - Add a HostApp repro page and an Appium UI test for issue #34823.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Core/src/Platform/Windows/WebViewExtensions.cs | Implements background + preferred color scheme update logic for WebView2. |
| src/Core/src/Handlers/WebView/WebViewHandler.cs | Adds Windows mapper entry to update WebView background. |
| src/Core/src/Handlers/WebView/WebViewHandler.Windows.cs | Adds MapBackground and invokes background/theme update on WebView2 initialization. |
| src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34823.cs | Adds UI tests validating WebView appearance under light/dark app themes. |
| src/Controls/tests/TestCases.HostApp/Issues/Issue34823.cs | Adds HostApp reproduction UI with theme toggle + navigation to a WebView page. |
Comments suppressed due to low confidence (1)
src/Core/src/Handlers/WebView/WebViewHandler.Windows.cs:399
- PreferredColorScheme is only updated when UpdateBackground is invoked (on CoreWebView2Initialized and when Background changes). If the app theme changes while the WebView is already displayed, nothing re-applies PreferredColorScheme, so the WebView can stay stuck on the previous scheme. Consider subscribing to platformView.ActualThemeChanged (and unsubscribing on disconnect) to call UpdateBackground (or just update PreferredColorScheme) whenever the effective theme changes.
if (Handler is WebViewHandler handler)
{
sender.UpdateUserAgent(handler.VirtualView);
sender.UpdateBackground(handler.VirtualView);
if (sender.Source is not null)
{
handler.SyncPlatformCookies(sender.Source.ToString()).FireAndForget();
}
Comment on lines
28
to
+29
| [nameof(IView.FlowDirection)] = MapFlowDirection, | ||
| [nameof(IView.Background)] = MapBackground, |
There was a problem hiding this comment.
The WINDOWS section of the property mapper is mis-indented compared to the surrounding entries, which makes it easy to miss mappings in reviews/merges. Align the indentation with the other mapper entries inside the initializer.
Suggested change
| [nameof(IView.FlowDirection)] = MapFlowDirection, | |
| [nameof(IView.Background)] = MapBackground, | |
| [nameof(IView.FlowDirection)] = MapFlowDirection, | |
| [nameof(IView.Background)] = MapBackground, |
Comment on lines
+99
to
+103
| //TODO: Make it public in .NET 11. | ||
| internal static void MapBackground(IWebViewHandler handler, IWebView webView) | ||
| { | ||
| handler.PlatformView?.UpdateBackground(webView); | ||
| } |
There was a problem hiding this comment.
This TODO references ".NET 11" and suggests making MapBackground public, but mapper methods are internal implementation details and the repo is targeting main. Please either remove the TODO or clarify the intended action (e.g., linking to an issue/PR and/or explaining why this needs to be public).
| [Category(UITestCategories.WebView)] | ||
| public void WebViewWithDarkTheme() | ||
| { | ||
| App.WaitForElement("WebButton"); |
There was a problem hiding this comment.
The test taps "ThemeButton" without first waiting for it to exist. For UI test stability, add a WaitForElement("ThemeButton") before tapping it (especially on slower devices/CI).
Suggested change
| App.WaitForElement("WebButton"); | |
| App.WaitForElement("WebButton"); | |
| App.WaitForElement("ThemeButton"); |
Comment on lines
+78
to
+109
| helpPage.NavigatedTo += async (_, __) => | ||
| { | ||
| webView.Source = new HtmlWebViewSource | ||
| { | ||
| Html = """ | ||
| <html> | ||
| <head> | ||
| <meta name=\"viewport\" content=\"width=device-width, initial-scale=1.0\"> | ||
| <title>Preparing Help</title> | ||
| <style> | ||
| @media (prefers-color-scheme: dark) { | ||
| html, body { | ||
| color: white; | ||
| background-color: black; | ||
| } | ||
| } | ||
|
|
||
| @media (prefers-color-scheme: light) { | ||
| html, body { | ||
| color: black; | ||
| background-color: white; | ||
| } | ||
| } | ||
| </style> | ||
| </head> | ||
| <body> | ||
| <center><h1>Text on a web page</h1></center> | ||
| </body> | ||
| </html> | ||
| """ | ||
| }; | ||
| }; |
There was a problem hiding this comment.
WebView content is assigned via the NavigatedTo event handler, which introduces timing variability (and the handler is marked async but doesn't await). Consider setting webView.Source before PushAsync (or using a non-async handler) to reduce race/flakiness and remove the unnecessary async event subscription.
Comment on lines
+47
to
+63
| platformWebView.CoreWebView2.Profile.PreferredColorScheme = CoreWebView2PreferredColorScheme.Light; | ||
| } | ||
| } | ||
| else | ||
| { | ||
| if (platformWebView.CoreWebView2 is not null) | ||
| { | ||
| platformWebView.CoreWebView2.Profile.PreferredColorScheme = platformWebView.ActualTheme switch | ||
| { | ||
| ElementTheme.Dark => CoreWebView2PreferredColorScheme.Dark, | ||
| ElementTheme.Light => CoreWebView2PreferredColorScheme.Light, | ||
| _ => CoreWebView2PreferredColorScheme.Auto | ||
| }; | ||
| } | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
When a non-null Background is set, PreferredColorScheme is forced to Light. That can conflict with the app/theme (e.g., if an app sets a dark WebView background for dark mode, web content using prefers-color-scheme will still get Light). Consider deriving PreferredColorScheme from platformWebView.ActualTheme in this branch as well, or basing it on the background color’s luminance if the intent is readability.
Suggested change
| platformWebView.CoreWebView2.Profile.PreferredColorScheme = CoreWebView2PreferredColorScheme.Light; | |
| } | |
| } | |
| else | |
| { | |
| if (platformWebView.CoreWebView2 is not null) | |
| { | |
| platformWebView.CoreWebView2.Profile.PreferredColorScheme = platformWebView.ActualTheme switch | |
| { | |
| ElementTheme.Dark => CoreWebView2PreferredColorScheme.Dark, | |
| ElementTheme.Light => CoreWebView2PreferredColorScheme.Light, | |
| _ => CoreWebView2PreferredColorScheme.Auto | |
| }; | |
| } | |
| } | |
| } | |
| platformWebView.CoreWebView2.Profile.PreferredColorScheme = GetPreferredColorScheme(platformWebView.ActualTheme); | |
| } | |
| } | |
| else | |
| { | |
| if (platformWebView.CoreWebView2 is not null) | |
| { | |
| platformWebView.CoreWebView2.Profile.PreferredColorScheme = GetPreferredColorScheme(platformWebView.ActualTheme); | |
| } | |
| } | |
| } | |
| static CoreWebView2PreferredColorScheme GetPreferredColorScheme(ElementTheme actualTheme) => | |
| actualTheme switch | |
| { | |
| ElementTheme.Dark => CoreWebView2PreferredColorScheme.Dark, | |
| ElementTheme.Light => CoreWebView2PreferredColorScheme.Light, | |
| _ => CoreWebView2PreferredColorScheme.Auto | |
| }; |
MauiBot
added
s/agent-changes-requested
This was referenced Apr 20, 2026
Open
kubaflo
requested changes
Apr 20, 2026
Contributor
kubaflo
left a comment
kubaflo
left a comment
There was a problem hiding this comment.
Could you please add a snapshot?
Contributor
Author
@kubaflo , I have added the snapshots for all platform |
MauiBot
reviewed
May 8, 2026
Collaborator
MauiBot
left a comment
MauiBot
left a comment
There was a problem hiding this comment.
Expert Review — 7 findings
See inline comments for details.
| if (platformWebView.CoreWebView2 is not null) | ||
| { | ||
| platformWebView.CoreWebView2.Profile.PreferredColorScheme = CoreWebView2PreferredColorScheme.Auto; | ||
| platformWebView.CoreWebView2.Profile.PreferredColorScheme = platformWebView.ActualTheme switch |
Collaborator
There was a problem hiding this comment.
UpdateBackground only runs from MapBackground (Background changes) and OnCoreWebView2Initialized (one-shot). When Application.UserAppTheme changes after the WebView is already initialized, the mapping is never re-applied — so an existing WebView will not follow runtime theme changes. Consider subscribing to platformWebView.ActualThemeChanged (or hooking the handler's window theme) and re-running the mapping when it fires.
| { | ||
| ElementTheme.Dark => CoreWebView2PreferredColorScheme.Dark, | ||
| ElementTheme.Light => CoreWebView2PreferredColorScheme.Light, | ||
| _ => CoreWebView2PreferredColorScheme.Auto |
Collaborator
There was a problem hiding this comment.
ActualTheme returns Default until the element is loaded into the visual tree. OnCoreWebView2Initialized may fire before the WebView's Loaded event, in which case this maps to Auto and silently reverts to the OS theme — the very bug this PR is fixing. Recommend deferring this until platformWebView.IsLoaded or hooking ActualThemeChanged.
| App.WaitForElement("WebButton"); | ||
| App.Tap("WebButton"); | ||
| VerifyScreenshot(); | ||
| } |
Collaborator
There was a problem hiding this comment.
App.Tap("WebButton") triggers PushAsync(helpPage) and starts WebView2 + HTML parsing — both async. VerifyScreenshot() is called immediately, so the screenshot is captured before the page navigation animation finishes and before HTML rendering completes. This is the most likely cause of the gate's 55.62% snapshot diff. Add App.WaitForElement for an in-page automation hook, or wait for navigation to complete before capturing.
| { | ||
| App.WaitForElement("WebButton"); | ||
| App.Tap("ThemeButton"); | ||
| App.Tap("WebButton"); |
Collaborator
There was a problem hiding this comment.
Same issue as WebViewWithLightTheme: tap-then-screenshot has no wait. In addition, the theme toggle in OnThemeButtonClicked is propagated asynchronously through MAUI to WinUI's RequestedTheme. Without a small wait between Tap("ThemeButton") and Tap("WebButton"), the new WebView's ActualTheme may still be Light when UpdateBackground runs.
| var webButton = new Button | ||
| { | ||
| Text = "Switch to web page", | ||
| AutomationId = "WebButton", |
Collaborator
There was a problem hiding this comment.
Indentation uses spaces here while surrounding lines use tabs.
|
|
||
| helpPage.NavigatedTo += async (_, __) => | ||
| { | ||
| webView.Source = new HtmlWebViewSource |
Collaborator
There was a problem hiding this comment.
Setting Source inside NavigatedTo mixes navigation and content lifecycle. Consider setting webView.Source synchronously before PushAsync and exposing an AutomationId on the WebView so the test can WaitForElement for it before screenshotting.
MauiBot
added
s/agent-review-incomplete
and removed
s/agent-changes-requested
This was referenced May 8, 2026
This was referenced May 12, 2026
Contributor
|
/review -b feature/regression-check -p windows |
2 similar comments
Contributor
|
/review -b feature/regression-check -p windows |
Contributor
|
/review -b feature/regression-check -p windows |
MauiBot
suggested changes
May 19, 2026
Collaborator
MauiBot
left a comment
MauiBot
left a comment
There was a problem hiding this comment.
🤖 Automated review — alternative fix proposed
The expert-reviewer evaluation compared the PR fix against #1 automatically generated candidates and selected try-fix-1 as the strongest fix.
Why: try-fix-1 (equivalent to pr-plus-reviewer) is the only empirically validated candidate that fixes the dark-theme regression. It reads the app theme from XamlRoot.Content.RequestedTheme (where MAUI writes UserAppTheme) instead of the WebView2's own ActualTheme, which is unreliable at CoreWebView2Initialized time. Dark-theme diff drops from 55.62% (PR fix) to 7.39% and the residue is a pre-existing title-bar capture artifact, not a theme issue.
Please consider applying the candidate diff below (or use it as guidance). Once you push an update, this workflow will re-trigger and re-evaluate.
Candidate diff (`try-fix-1`)
diff --git a/src/Core/src/Platform/Windows/WebViewExtensions.cs b/src/Core/src/Platform/Windows/WebViewExtensions.cs
index 452c4b7126..61f6c60dff 100644
--- a/src/Core/src/Platform/Windows/WebViewExtensions.cs
+++ b/src/Core/src/Platform/Windows/WebViewExtensions.cs
@@ -51,7 +51,16 @@ namespace Microsoft.Maui.Platform
{
if (platformWebView.CoreWebView2 is not null)
{
- platformWebView.CoreWebView2.Profile.PreferredColorScheme = platformWebView.ActualTheme switch
+ // Read the theme from the WebView's XamlRoot Content (the Window root) rather than
+ // the WebView2's own ActualTheme. ActualTheme returns ElementTheme.Default until the
+ // element is loaded and theme inheritance has propagated, which is not guaranteed at
+ // the time CoreWebView2Initialized fires. The Window root, by contrast, is where MAUI
+ // applies UserAppTheme (see Application.Windows.cs OnRequestedThemeChangedPlatform),
+ // so its RequestedTheme reliably reflects the MAUI app theme.
+ var rootTheme = (platformWebView.XamlRoot?.Content as FrameworkElement)?.RequestedTheme
+ ?? ElementTheme.Default;
+
+ platformWebView.CoreWebView2.Profile.PreferredColorScheme = rootTheme switch
{
ElementTheme.Dark => CoreWebView2PreferredColorScheme.Dark,
ElementTheme.Light => CoreWebView2PreferredColorScheme.Light,
MauiBot
suggested changes
May 19, 2026
Collaborator
MauiBot
left a comment
MauiBot
left a comment
There was a problem hiding this comment.
🤖 Automated review — alternative fix proposed
The expert-reviewer evaluation compared the PR fix against #1 automatically generated candidates and selected try-fix-1 as the strongest fix.
Why: try-fix-1 is a structural superset of both the PR and pr-plus-reviewer: it removes the hard-coded Light in the if-branch AND subscribes to WebView2.ActualThemeChanged so the WebView's PreferredColorScheme tracks the resolved WinUI theme even when IWebView.Background never changes (the issue's actual repro on a vanilla WebView). Build is clean, gate passes, lifecycle is symmetric with the existing CoreWebView2Initialized subscription. pr-plus-reviewer only fixes the symmetric code-path bug and still leaves the reactivity gap.
Please consider applying the candidate diff below (or use it as guidance). Once you push an update, this workflow will re-trigger and re-evaluate.
Candidate diff (`try-fix-1`)
diff --git a/src/Core/src/Handlers/WebView/WebViewHandler.Windows.cs b/src/Core/src/Handlers/WebView/WebViewHandler.Windows.cs
index a9922e15fd..252ed6d58c 100644
--- a/src/Core/src/Handlers/WebView/WebViewHandler.Windows.cs
+++ b/src/Core/src/Handlers/WebView/WebViewHandler.Windows.cs
@@ -344,6 +344,7 @@ namespace Microsoft.Maui.Handlers
{
_handler = new(handler);
platformView.CoreWebView2Initialized += OnCoreWebView2Initialized;
+ platformView.ActualThemeChanged += OnActualThemeChanged;
}
public void Connect(Window window)
@@ -355,6 +356,7 @@ namespace Microsoft.Maui.Handlers
public void Disconnect(WebView2 platformView)
{
platformView.CoreWebView2Initialized -= OnCoreWebView2Initialized;
+ platformView.ActualThemeChanged -= OnActualThemeChanged;
if (platformView.CoreWebView2 is CoreWebView2 webView2)
{
@@ -382,6 +384,17 @@ namespace Microsoft.Maui.Handlers
}
}
+ // Fires whenever the WebView2's resolved theme changes (OS toggle, MAUI app theme
+ // toggle, or any ancestor RequestedTheme override). Keeps CoreWebView2's
+ // PreferredColorScheme in sync even when IWebView.Background has not changed.
+ void OnActualThemeChanged(FrameworkElement sender, object args)
+ {
+ if (sender is WebView2 platformWebView)
+ {
+ platformWebView.UpdatePreferredColorScheme();
+ }
+ }
+
void OnCoreWebView2Initialized(WebView2 sender, CoreWebView2InitializedEventArgs args)
{
sender.CoreWebView2.HistoryChanged += OnHistoryChanged;
diff --git a/src/Core/src/Platform/Windows/WebViewExtensions.cs b/src/Core/src/Platform/Windows/WebViewExtensions.cs
index 452c4b7126..eb821daa06 100644
--- a/src/Core/src/Platform/Windows/WebViewExtensions.cs
+++ b/src/Core/src/Platform/Windows/WebViewExtensions.cs
@@ -41,24 +41,29 @@ namespace Microsoft.Maui.Platform
if (backgroundColor is not null)
{
platformWebView.DefaultBackgroundColor = backgroundColor.ToWindowsColor();
-
- if (platformWebView.CoreWebView2 is not null)
- {
- platformWebView.CoreWebView2.Profile.PreferredColorScheme = CoreWebView2PreferredColorScheme.Light;
- }
}
- else
+
+ // Keep the WebView2's preferred color scheme in sync with the resolved WinUI
+ // ActualTheme regardless of whether the user supplied an explicit background.
+ platformWebView.UpdatePreferredColorScheme();
+ }
+
+ // Maps the WebView2's effective WinUI ActualTheme onto CoreWebView2.Profile.PreferredColorScheme
+ // so that web content's prefers-color-scheme media query honors the MAUI app theme rather than
+ // the OS system theme. Safe to call before CoreWebView2 is initialized.
+ internal static void UpdatePreferredColorScheme(this WebView2 platformWebView)
+ {
+ if (platformWebView.CoreWebView2 is null)
{
- if (platformWebView.CoreWebView2 is not null)
- {
- platformWebView.CoreWebView2.Profile.PreferredColorScheme = platformWebView.ActualTheme switch
- {
- ElementTheme.Dark => CoreWebView2PreferredColorScheme.Dark,
- ElementTheme.Light => CoreWebView2PreferredColorScheme.Light,
- _ => CoreWebView2PreferredColorScheme.Auto
- };
- }
+ return;
}
+
+ platformWebView.CoreWebView2.Profile.PreferredColorScheme = platformWebView.ActualTheme switch
+ {
+ ElementTheme.Dark => CoreWebView2PreferredColorScheme.Dark,
+ ElementTheme.Light => CoreWebView2PreferredColorScheme.Light,
+ _ => CoreWebView2PreferredColorScheme.Auto
+ };
}
public static void UpdateUserAgent(this WebView2 platformWebView, IWebView webView)
This was referenced May 20, 2026
Contributor
|
/review -b feature/regression-check -p windows |
1 similar comment
Contributor
|
/review -b feature/regression-check -p windows |
Collaborator
🤖 AI Summary
📊 Review Session —
|
| Test | Without Fix (expect FAIL) | With Fix (expect PASS) |
|---|---|---|
🖥️ Issue34823 Issue34823 |
✅ FAIL — 602s | ✅ PASS — 493s |
🔴 Without fix — 🖥️ Issue34823: FAIL ✅ · 602s
Determining projects to restore...
Restored D:\a\1\s\src\Graphics\src\Graphics\Graphics.csproj (in 47.68 sec).
Restored D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj (in 47.88 sec).
Restored D:\a\1\s\src\Essentials\src\Essentials.csproj (in 24 ms).
Restored D:\a\1\s\src\Core\src\Core.csproj (in 238 ms).
Restored D:\a\1\s\src\Graphics\src\Graphics.Win2D\Graphics.Win2D.csproj (in 347 ms).
Restored D:\a\1\s\src\Core\maps\src\Maps.csproj (in 4.83 sec).
Restored D:\a\1\s\src\Controls\src\Xaml\Controls.Xaml.csproj (in 33 ms).
Restored D:\a\1\s\src\Controls\Maps\src\Controls.Maps.csproj (in 32 ms).
Restored D:\a\1\s\src\Controls\Foldable\src\Controls.Foldable.csproj (in 25 ms).
Restored D:\a\1\s\src\BlazorWebView\src\Maui\Microsoft.AspNetCore.Components.WebView.Maui.csproj (in 74 ms).
Restored D:\a\1\s\src\Controls\tests\TestCases.HostApp\Controls.TestCases.HostApp.csproj (in 5.28 sec).
3 of 14 projects are up-to-date for restore.
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Graphics -> D:\a\1\s\artifacts\bin\Graphics\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Graphics.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Graphics.Win2D -> D:\a\1\s\artifacts\bin\Graphics.Win2D\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Graphics.Win2D.WinUI.Desktop.dll
Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Essentials.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Core -> D:\a\1\s\artifacts\bin\Core\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Maps -> D:\a\1\s\artifacts\bin\Maps\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Maps.dll
Controls.BindingSourceGen -> D:\a\1\s\artifacts\bin\Controls.BindingSourceGen\Debug\netstandard2.0\Microsoft.Maui.Controls.BindingSourceGen.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Controls.Core -> D:\a\1\s\artifacts\bin\Controls.Core\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Controls.Xaml -> D:\a\1\s\artifacts\bin\Controls.Xaml\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Xaml.dll
Controls.Foldable -> D:\a\1\s\artifacts\bin\Controls.Foldable\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Foldable.dll
Microsoft.AspNetCore.Components.WebView.Maui -> D:\a\1\s\artifacts\bin\Microsoft.AspNetCore.Components.WebView.Maui\Debug\net10.0-windows10.0.19041.0\Microsoft.AspNetCore.Components.WebView.Maui.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Controls.Maps -> D:\a\1\s\artifacts\bin\Controls.Maps\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Maps.dll
Controls.TestCases.HostApp -> D:\a\1\s\artifacts\bin\Controls.TestCases.HostApp\Debug\net10.0-windows10.0.19041.0\win-x64\Controls.TestCases.HostApp.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:06:08.84
Determining projects to restore...
Restored D:\a\1\s\src\TestUtils\src\VisualTestUtils\VisualTestUtils.csproj (in 729 ms).
Restored D:\a\1\s\src\TestUtils\src\UITest.NUnit\UITest.NUnit.csproj (in 1.74 sec).
Restored D:\a\1\s\src\TestUtils\src\UITest.Core\UITest.Core.csproj (in 3 ms).
Restored D:\a\1\s\src\TestUtils\src\VisualTestUtils.MagickNet\VisualTestUtils.MagickNet.csproj (in 4.38 sec).
Restored D:\a\1\s\src\TestUtils\src\UITest.Appium\UITest.Appium.csproj (in 2.85 sec).
Restored D:\a\1\s\src\TestUtils\src\UITest.Analyzers\UITest.Analyzers.csproj (in 10.54 sec).
Restored D:\a\1\s\src\Controls\tests\CustomAttributes\Controls.CustomAttributes.csproj (in 4 ms).
Restored D:\a\1\s\src\Controls\tests\TestCases.WinUI.Tests\Controls.TestCases.WinUI.Tests.csproj (in 9.31 sec).
7 of 15 projects are up-to-date for restore.
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Graphics -> D:\a\1\s\artifacts\bin\Graphics\Debug\net10.0\Microsoft.Maui.Graphics.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0\Microsoft.Maui.Essentials.dll
Controls.CustomAttributes -> D:\a\1\s\artifacts\bin\Controls.CustomAttributes\Debug\net10.0\Controls.CustomAttributes.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Core -> D:\a\1\s\artifacts\bin\Core\Debug\net10.0\Microsoft.Maui.dll
Controls.Core.Design -> D:\a\1\s\artifacts\bin\Controls.Core.Design\Debug\net472\Microsoft.Maui.Controls.DesignTools.dll
Controls.BindingSourceGen -> D:\a\1\s\artifacts\bin\Controls.BindingSourceGen\Debug\netstandard2.0\Microsoft.Maui.Controls.BindingSourceGen.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Controls.Core -> D:\a\1\s\artifacts\bin\Controls.Core\Debug\net10.0\Microsoft.Maui.Controls.dll
UITest.Core -> D:\a\1\s\artifacts\bin\UITest.Core\Debug\net10.0\UITest.Core.dll
UITest.Appium -> D:\a\1\s\artifacts\bin\UITest.Appium\Debug\net10.0\UITest.Appium.dll
UITest.NUnit -> D:\a\1\s\artifacts\bin\UITest.NUnit\Debug\net10.0\UITest.NUnit.dll
VisualTestUtils -> D:\a\1\s\artifacts\bin\VisualTestUtils\Debug\netstandard2.0\VisualTestUtils.dll
VisualTestUtils.MagickNet -> D:\a\1\s\artifacts\bin\VisualTestUtils.MagickNet\Debug\netstandard2.0\VisualTestUtils.MagickNet.dll
UITest.Analyzers -> D:\a\1\s\artifacts\bin\UITest.Analyzers\Debug\netstandard2.0\UITest.Analyzers.dll
Controls.TestCases.WinUI.Tests -> D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
Test run for D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
NUnit3TestExecutor discovered 2 of 2 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 5/21/2026 11:08:54 AM WebViewWithDarkTheme Start
>>>>> 5/21/2026 11:08:54 AM FixtureSetup for WebViewWithDarkTheme
>>>>> 5/21/2026 11:09:07 AM WebViewWithDarkTheme Stop
>>>>> 5/21/2026 11:09:07 AM Log types:
Failed WebViewWithDarkTheme [18 s]
Error Message:
VisualTestUtils.VisualTestFailedException :
Snapshot different than baseline: WebViewWithDarkTheme.png (2.81% difference)
If the correct baseline has changed (this isn't a a bug), then update the baseline image.
See test attachment or download the build artifacts to get the new snapshot file.
More info: https://aka.ms/visual-test-workflow
Stack Trace:
at VisualTestUtils.VisualRegressionTester.Fail(String message) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 162
at VisualTestUtils.VisualRegressionTester.VerifyMatchesSnapshot(String name, ImageSnapshot actualImage, String environmentName, ITestContext testContext) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 123
at Microsoft.Maui.TestCases.Tests.UITest.<VerifyScreenshot>g__Verify|13_0(String name, <>c__DisplayClass13_0&) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 477
at Microsoft.Maui.TestCases.Tests.UITest.VerifyScreenshot(String name, Nullable`1 retryDelay, Nullable`1 retryTimeout, Int32 cropLeft, Int32 cropRight, Int32 cropTop, Int32 cropBottom, Double tolerance, Boolean includeTitleBar) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 309
at Microsoft.Maui.TestCases.Tests.Issues.Issue34823.WebViewWithDarkTheme() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34823.cs:line 34
at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
>>>>> 5/21/2026 11:09:12 AM WebViewWithLightTheme Start
>>>>> 5/21/2026 11:09:12 AM FixtureSetup for WebViewWithLightTheme
>>>>> 5/21/2026 11:09:22 AM WebViewWithLightTheme Stop
>>>>> 5/21/2026 11:09:22 AM Log types:
NUnit Adapter 4.5.0.0: Test execution complete
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.12] Discovering: Controls.TestCases.WinUI.Tests
[xUnit.net 00:00:00.31] Discovered: Controls.TestCases.WinUI.Tests
Failed WebViewWithLightTheme [12 s]
Error Message:
VisualTestUtils.VisualTestFailedException :
Snapshot different than baseline: WebViewWithLightTheme.png (2.64% difference)
If the correct baseline has changed (this isn't a a bug), then update the baseline image.
See test attachment or download the build artifacts to get the new snapshot file.
More info: https://aka.ms/visual-test-workflow
Stack Trace:
at VisualTestUtils.VisualRegressionTester.Fail(String message) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 162
at VisualTestUtils.VisualRegressionTester.VerifyMatchesSnapshot(String name, ImageSnapshot actualImage, String environmentName, ITestContext testContext) in /_/src/TestUtils/src/VisualTestUtils/VisualRegressionTester.cs:line 123
at Microsoft.Maui.TestCases.Tests.UITest.<VerifyScreenshot>g__Verify|13_0(String name, <>c__DisplayClass13_0&) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 477
at Microsoft.Maui.TestCases.Tests.UITest.VerifyScreenshot(String name, Nullable`1 retryDelay, Nullable`1 retryTimeout, Int32 cropLeft, Int32 cropRight, Int32 cropTop, Int32 cropBottom, Double tolerance, Boolean includeTitleBar) in /_/src/Controls/tests/TestCases.Shared.Tests/UITest.cs:line 309
at Microsoft.Maui.TestCases.Tests.Issues.Issue34823.WebViewWithLightTheme() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34823.cs:line 24
at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
Total tests: 2
Failed: 2
Test Run Failed.
Total time: 50.0505 Seconds
🟢 With fix — 🖥️ Issue34823: PASS ✅ · 493s
Determining projects to restore...
All projects are up-to-date for restore.
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Graphics -> D:\a\1\s\artifacts\bin\Graphics\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Graphics.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Essentials.dll
Graphics.Win2D -> D:\a\1\s\artifacts\bin\Graphics.Win2D\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Graphics.Win2D.WinUI.Desktop.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Core -> D:\a\1\s\artifacts\bin\Core\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.dll
Controls.BindingSourceGen -> D:\a\1\s\artifacts\bin\Controls.BindingSourceGen\Debug\netstandard2.0\Microsoft.Maui.Controls.BindingSourceGen.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Maps -> D:\a\1\s\artifacts\bin\Maps\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Maps.dll
Controls.Core -> D:\a\1\s\artifacts\bin\Controls.Core\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Microsoft.AspNetCore.Components.WebView.Maui -> D:\a\1\s\artifacts\bin\Microsoft.AspNetCore.Components.WebView.Maui\Debug\net10.0-windows10.0.19041.0\Microsoft.AspNetCore.Components.WebView.Maui.dll
Controls.Foldable -> D:\a\1\s\artifacts\bin\Controls.Foldable\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Foldable.dll
Controls.Maps -> D:\a\1\s\artifacts\bin\Controls.Maps\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Maps.dll
Controls.Xaml -> D:\a\1\s\artifacts\bin\Controls.Xaml\Debug\net10.0-windows10.0.19041.0\Microsoft.Maui.Controls.Xaml.dll
Controls.TestCases.HostApp -> D:\a\1\s\artifacts\bin\Controls.TestCases.HostApp\Debug\net10.0-windows10.0.19041.0\win-x64\Controls.TestCases.HostApp.dll
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:06:00.91
Determining projects to restore...
All projects are up-to-date for restore.
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Graphics -> D:\a\1\s\artifacts\bin\Graphics\Debug\net10.0\Microsoft.Maui.Graphics.dll
Controls.CustomAttributes -> D:\a\1\s\artifacts\bin\Controls.CustomAttributes\Debug\net10.0\Controls.CustomAttributes.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0\Microsoft.Maui.Essentials.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Core -> D:\a\1\s\artifacts\bin\Core\Debug\net10.0\Microsoft.Maui.dll
Controls.Core.Design -> D:\a\1\s\artifacts\bin\Controls.Core.Design\Debug\net472\Microsoft.Maui.Controls.DesignTools.dll
Controls.BindingSourceGen -> D:\a\1\s\artifacts\bin\Controls.BindingSourceGen\Debug\netstandard2.0\Microsoft.Maui.Controls.BindingSourceGen.dll
##vso[build.updatebuildnumber]10.0.80-ci+azdo.14158620
Controls.Core -> D:\a\1\s\artifacts\bin\Controls.Core\Debug\net10.0\Microsoft.Maui.Controls.dll
UITest.Core -> D:\a\1\s\artifacts\bin\UITest.Core\Debug\net10.0\UITest.Core.dll
UITest.Appium -> D:\a\1\s\artifacts\bin\UITest.Appium\Debug\net10.0\UITest.Appium.dll
UITest.NUnit -> D:\a\1\s\artifacts\bin\UITest.NUnit\Debug\net10.0\UITest.NUnit.dll
VisualTestUtils -> D:\a\1\s\artifacts\bin\VisualTestUtils\Debug\netstandard2.0\VisualTestUtils.dll
VisualTestUtils.MagickNet -> D:\a\1\s\artifacts\bin\VisualTestUtils.MagickNet\Debug\netstandard2.0\VisualTestUtils.MagickNet.dll
UITest.Analyzers -> D:\a\1\s\artifacts\bin\UITest.Analyzers\Debug\netstandard2.0\UITest.Analyzers.dll
Controls.TestCases.WinUI.Tests -> D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
Test run for D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in D:\a\1\s\artifacts\bin\Controls.TestCases.WinUI.Tests\Debug\net10.0\Controls.TestCases.WinUI.Tests.dll
NUnit3TestExecutor discovered 2 of 2 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 5/21/2026 11:17:13 AM WebViewWithDarkTheme Start
>>>>> 5/21/2026 11:17:13 AM FixtureSetup for WebViewWithDarkTheme
>>>>> 5/21/2026 11:17:26 AM WebViewWithDarkTheme Stop
Passed WebViewWithDarkTheme [13 s]
>>>>> 5/21/2026 11:17:27 AM WebViewWithLightTheme Start
>>>>> 5/21/2026 11:17:27 AM FixtureSetup for WebViewWithLightTheme
>>>>> 5/21/2026 11:17:36 AM WebViewWithLightTheme Stop
NUnit Adapter 4.5.0.0: Test execution complete
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.11] Discovering: Controls.TestCases.WinUI.Tests
[xUnit.net 00:00:00.34] Discovered: Controls.TestCases.WinUI.Tests
Passed WebViewWithLightTheme [10 s]
Test Run Successful.
Total tests: 2
Passed: 2
Total time: 37.6387 Seconds
📁 Fix files reverted (1 files)
src/Core/src/Platform/Windows/WebViewExtensions.cs
🧪 UI Tests — ViewBaseTests,WebView
Detected UI test categories: ViewBaseTests,WebView
🧪 UI Test Execution Results
⏭️ SKIPPED — 0 passed, 0 failed, 2 skipped (platform: windows)
| Category | Result | Tests | Duration | Notes |
|---|---|---|---|---|
ViewBaseTests |
⏭️ SKIPPED | — | 0s | Runner threw an exception |
WebView |
⏭️ SKIPPED | — | 0s | Runner threw an exception |
Failures here are informational only — they do not block the gate or affect try-fix candidate scoring.
🔍 Pre-Flight — Context & Validation
PR #35037 — Pre-flight summary
Issue (#34823)
- Title: WebView on Windows Does Not Inherit App Theme
- Reported by: david-maw (partner: syncfusion)
- Affected platform: Windows (Android already works)
- Problem:
WebView2on Windows hosts content in an out-of-process Edge/Chromium browser. Web content'sprefers-color-schemeCSS media query is driven byCoreWebView2.Profile.PreferredColorScheme. Its default value isAuto, which reads the OS system theme directly — it does NOT follow MAUI'sApplication.UserAppTheme/RequestedTheme. As a result, if the user picksAppTheme.Darkin a MAUI app on a light-themed Windows, all WinUI controls go dark viaFrameworkElement.RequestedThemepropagation, but the embeddedWebView2keeps rendering in light mode. - User's workaround: explicitly set
wv.CoreWebView2.Profile.PreferredColorSchemefromApp.Current.RequestedThemebefore showing the page.
PR #35037 — Proposed fix
- Author: devanathan-vaithiyanathan (community/syncfusion)
- Files changed: 11 (172 / -1). Only one production file modified:
src/Core/src/Platform/Windows/WebViewExtensions.cs
- Test changes: new
Issue34823host app page + shared NUnit test (WebViewWithLightTheme,WebViewWithDarkTheme) + screenshot snapshots for Windows/iOS/Mac.
Diff (production code)
// In UpdateBackground, else branch (no explicit background color):
- platformWebView.CoreWebView2.Profile.PreferredColorScheme = CoreWebView2PreferredColorScheme.Auto;
+ platformWebView.CoreWebView2.Profile.PreferredColorScheme = platformWebView.ActualTheme switch
+ {
+ ElementTheme.Dark => CoreWebView2PreferredColorScheme.Dark,
+ ElementTheme.Light => CoreWebView2PreferredColorScheme.Light,
+ _ => CoreWebView2PreferredColorScheme.Auto
+ };What the PR does correctly
- Uses
WebView2.ActualTheme, which already reflects the effective WinUIElementThemeafterRequestedThemeinheritance from the rootFrameworkElementthat MAUI mutates whenUserAppThemechanges. - Localized change inside the existing
UpdateBackgroundextension — small surface area. - Adds a UI test that exercises both themes (gate confirmed PASS-with-fix / FAIL-without-fix).
Weaknesses / questions raised by the PR
- Runtime theme switching while a WebView is already on screen is not handled.
The mapping only runs whenUpdateBackgroundis invoked — i.e. on handler connect, onCoreWebView2Initialized, and whenIWebView.Backgroundchanges. There is no subscription toWebView2.ActualThemeChanged. The test passes only because it creates a new WebView after toggling the theme; an app that keeps the same WebView instance and togglesUserAppThemeafterward will see its WinUI chrome update but its web content stuck on the previous scheme. (This is essentially the same scenario the original issue describes.) - Coupling to
UpdateBackgroundis semantically odd.PreferredColorSchemecontrols the CSS media-query state in the embedded browser; it is orthogonal toIWebView.Background. The PR also leaves the other branch (when an explicit background color is set) hard-codingPreferredColorScheme.Light, which is unrelated to "the user picked a background color" — this was a pre-existing oddity but the PR doesn't address it. - No coverage of the "explicit background color + theme" interaction. With the PR, if a developer sets
WebView.BackgroundColor, the color scheme reverts toLightregardless ofAppTheme.Dark. PlatformAffected.UWPis used in the new host-app[Issue]attribute — minor metadata nit (newer code usesPlatformAffected.UWPconsistently, so this is fine).
Gate result (provided)
✅ PASSED — tests FAIL without fix, PASS with fix.
Implication for try-fix candidates
A "demonstrably better" alternative should either:
- React to runtime theme changes on an existing WebView (subscribe to
ActualThemeChanged), and/or - Cleanly separate the color-scheme concern from
UpdateBackgroundso the explicit-background-color path also respects the app theme.
🔧 Fix — Analysis & Comparison
Try-Fix aggregate — PR #35037 (Windows WebView theme inheritance)
Three meaningfully-different fix approaches were generated and compared against the PR's submitted fix.
| # | Approach | Code surface | Reacts to runtime UserAppTheme toggles |
Fixes pre-existing forced-Light on background-color path |
Verdict vs PR |
|---|---|---|---|---|---|
| PR | One-shot mapping inside UpdateBackground (else branch only). Reads WebView2.ActualTheme. |
1 file (extension) | ❌ No | ❌ No | Baseline |
| try-fix-1 | Extract UpdatePreferredColorScheme; subscribe to WebView2.ActualThemeChanged in handler. |
2 files (extension + handler) | ✅ Yes | ✅ Yes | Demonstrably better |
| try-fix-2 | Apply mapping unconditionally inside UpdateBackground (extract helper); drop forced-Light in background-color branch. No handler change. |
1 file | ❌ No | ✅ Yes | Smaller, better than PR but less complete |
| try-fix-3 | Drive from Application.RequestedTheme + RequestedThemeChanged in Controls layer. |
2+ files crossing Core↔Controls | ✅ Yes (if subscription in Controls) | ✅ Yes | More semantically accurate, but architecturally heavier; collapses to the PR if reduced to Core only. |
Stop condition
- After three candidates with materially different mechanics (one-shot helper + handler reactivity / one-shot helper only / Controls-layer reactive subscription), further variations would be trivial. Generation stopped.
Recommended winner
try-fix-1 — minimal handler addition that also fixes the underlying issue's actual scenario (runtime theme toggle on an existing WebView), while keeping the well-understood ActualTheme mechanism that WinUI gives us for free.
Caveats
- Test execution was skipped for all three candidates: the gate's UI snapshot tests (
WebViewWithLightTheme,WebViewWithDarkTheme) require themaui-pr-uitestsHelix/Appium harness which is not available in this lightweight CI environment. The candidates were not committed/applied to the working tree. Reasoning is static (compile-level / API-availability / lifetime). - Gate result for the PR as submitted is ✅ PASSED (provided externally).
- Per autonomous-execution policy, environment blocker on UI snapshots was treated as "skip and continue" rather than "stop".
Per-candidate details
try-fix-1/content.md— Reactive viaActualThemeChangedtry-fix-2/content.md— Minimal one-file change, no reactivitytry-fix-3/content.md— Controls-layerRequestedThemeChangedsubscription
📋 Report — Final Recommendation
PR #35037 — Comparative analysis of candidates
Issue: #34823 — Windows WebView does not inherit MAUI app theme.
Candidates
| Candidate | Reactive to runtime theme toggles | Fixes pre-existing forced-Light on background-color branch |
Code surface | Gate / regression test status |
|---|---|---|---|---|
pr |
❌ No | ❌ No | 1 file | ✅ Gate PASS (initial-render path only) |
pr-plus-reviewer |
✅ Yes (ActualThemeChanged) |
✅ Yes | 2 files | ✅ Expected PASS (same mapping; superset of PR) |
try-fix-1 |
✅ Yes (ActualThemeChanged) |
✅ Yes | 2 files | |
try-fix-2 |
❌ No | ✅ Yes | 1 file | |
try-fix-3 |
✅ Yes (Controls-layer RequestedThemeChanged) |
✅ Yes | 2+ files crossing Core↔Controls |
Discussion
The gate has already proven the PR's mapping is correct for the initial-render scenario, so all candidates that retain that mapping (PR, pr-plus-reviewer, try-fix-1, try-fix-2, try-fix-3) are equivalent for the verified test. The differentiation is in two unverified-but-statically-evident axes:
- Live
UserAppThemetoggle on an already-visible WebView. The original issue scenario is exactly this. The PR's fix does not handle it.pr-plus-reviewer,try-fix-1, andtry-fix-3do (via different subscription mechanisms).try-fix-2does not. - Pre-existing
BackgroundColor + AppTheme.Darkregression. The PR leaves thebackgroundColor is not nullbranch hard-codingPreferredColorScheme.Light.pr-plus-reviewer,try-fix-1,try-fix-2, andtry-fix-3all unify the branches and fix this latent bug. The PR does not.
Ranking rules applied
- No candidate failed regression tests. All passed-or-skipped. Tie-breaker is therefore static quality + breadth of issue coverage.
pr-plus-reviewerstrictly dominatespr(same code + extra reactivity + extra branch fix).pr-plus-reviewerandtry-fix-1are mechanically equivalent in production code (same helper, sameActualThemeChangedsubscription, same removal of the forced-Lightline). They differ only in framing/provenance.try-fix-2is strictly weaker thanpr-plus-reviewer/try-fix-1on the reactivity axis.try-fix-3introduces Core↔Controls layering churn without adding capability beyondtry-fix-1(becauseActualThemealready reflectsUserAppThemevia WinUI inheritance MAUI sets up).pris weakest on both axes.
Ranking
pr-plus-reviewer— best of all axes; same mechanics astry-fix-1but presented as incremental review feedback on the submitted PR, which is the minimal-friction path forward.try-fix-1— functionally equivalent topr-plus-reviewer.try-fix-2— fixes the latent background-color branch bug; lacks live reactivity.try-fix-3— equivalent capability totry-fix-1but heavier surface (Core↔Controls).pr— verified-correct for the included test but leaves both the runtime-toggle scenario and the background-color branch unaddressed.
Winner
pr-plus-reviewer. It is a strict superset of the PR's current fix, addresses the two material gaps surfaced by expert review (runtime reactivity and the background-color branch), uses the same WinUI mechanism (ActualTheme) the PR author chose so risk is low, and keeps the change inside Microsoft.Maui.Core Windows code with no layering implications. Because the winner is pr-plus-reviewer, the PR can be advanced by applying the reviewer's inline findings rather than rewriting the fix.
kubaflo
approved these changes
May 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment whether this change resolves your issue. Thank you!
Issue Details
WebView2 on Windows hosts web content in a separate Edge/Chromium browser process that is architecturally decoupled from the WinUI element tree. When MAUI applies an app theme on Windows (e.g., AppTheme.Dark), it sets RequestedTheme on the root FrameworkElement, which propagates to all WinUI controls via normal element tree inheritance.
However, CoreWebView2.Profile.PreferredColorScheme — the browser-level setting that answers web content's prefers-color-scheme CSS media query — is never updated. Its default value is Auto, which reads the OS system theme directly, not the MAUI app theme. So if the user sets AppTheme.Dark in the app while the OS is in light mode, all WinUI controls go dark but the WebView still renders in light mode.
Description of Change
Added PreferredColorScheme logic in UpdateBackground(else part) extension method. It reads WebView2.ActualTheme effective WinUI element theme after inheritance) and maps it to the corresponding CoreWebView2PreferredColorScheme:
Note: This PR includes code changes from PR #34599 My fix is placed in the else block of UpdateBackground, so it needs to be rebased once PR #34599 is merged.
Issues Fixed
Fixes #34823
Tested the behavior in the following platforms.
Before.mp4
After.mp4