[Windows]Fix ContentPresenter Throws System.ArgumentException When Dynamically Assigning RefreshView or ScrollView Content

[devanathan-vaithiyanathan]

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 if this change resolves your issue. Thank you!

Issue Details

A previous fix (#30047) called DisconnectHandler before clearing the old content. This cascaded into child handlers and broke WinUI's internal pointer event routing when views were orphaned from the visual tree.

Description of Change

Get the platform view first (while the old panel is still live), detach it from any existing parent, then clear and add to the new panel. This avoids touching the internal handler hierarchy of views like ScrollView and RefreshView during a content switch.

Issues Fixed

Fixes #36298

Tested the behavior in the following platforms.

• Android
• Windows
• iOS
• Mac

Before	After
Windows Before.mov	Windows After.mp4

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 36430

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 36430"

[Jamesanand-IR]

Tested the fix and confirmed it is working correctly. Attached a video for reference.

Recording.2026-07-09.120247.mp4

[sheiksyedm]

/azp run maui-pr-uitests , maui-pr-devicetests

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[Copilot]

Pull request overview

This PR addresses a Windows regression where dynamically switching ContentPresenter content (notably when the content contains RefreshView/ScrollView) can crash with System.ArgumentException related to WinUI pointer event routing ownership. The implementation changes how Windows ContentPanel content is reparented to avoid disrupting WinUI’s internal routing state, and adds a regression UI test + HostApp repro page for issue #36298.

Changes:

• Windows: Update ContentViewHandler and BorderHandler to reparent the native element by detaching it from any existing parent before assigning it as ContentPanel.Content.
• Tests: Add HostApp issue page + Appium UI test for #36298 to cover the dynamic content-switching crash scenario.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/Core/src/Handlers/ContentView/ContentViewHandler.Windows.cs	Reparents the platform view before assigning it into ContentPanel.Content to avoid WinUI ownership exceptions during content switches.
src/Core/src/Handlers/Border/BorderHandler.Windows.cs	Applies the same reparenting approach for Border’s ContentPanel hosting.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue36298.cs	Adds an Appium regression test that exercises switching between two views to ensure no crash.
src/Controls/tests/TestCases.HostApp/Issues/Issue36298.cs	Adds the HostApp repro page used by the UI test (switching between RefreshView/ScrollView content).

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

[devanathan-vaithiyanathan]

Is this PR still needed - because the test couldn't catch the bug

@kubaflo , I modified the test, and it now catches the bug.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

[MauiBot]

Expert Review — 2 findings

See inline comments for details.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Windows handler reparenting — This only detaches children whose current parent is a ContentPanel or MauiPanel, but the Windows handler infrastructure also reparents views through plain WinUI Panel instances (see ViewHandler<T>.SetupContainer, which falls back to (Parent as Panel)?.Children). In that case this branch falls through and handler.PlatformView.Content = platformView still hits WinUI's 'element already has a parent' exception. Please add a Panel fallback (using CachedChildren for MauiPanel, otherwise Panel.Children) and apply the same helper to the duplicated BorderHandler.Windows.cs path.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Regression test coverage — The regression title and production fix target ContentPresenter/IContentView reparenting, but the sample host here is a ContentView. That exercises a different setup than the reported ContentPresenter/templated-content scenario, and the direct ContentView swap can succeed without proving the ContentPresenter crash is fixed. Please make the repro use a ContentPresenter (for example via a control template) and verify that it fails on the old handler code and passes with this fix.

[MauiBot]

Expert Review — 3 findings

See inline comments for details.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Handler Mapper and Property Patterns / Regression Prevention — The reparent-detach logic only matches ContentPanel and MauiPanel parents; any other native parent type is silently skipped, leaving the element attached to its old parent and able to reproduce the original WinUI COM exception this PR fixes. In particular, ViewHandlerOfT.Windows.cs.SetupContainer() wraps content that needs a container (Shadow, Clip, InputTransparent, etc.) in a WrapperView, which derives from Grid, not MauiPanel — so fwElement.Parent is WrapperView falls through both branches here with no detach performed. The codebase already has an established general-purpose pattern for this exact problem (PlatformView.Parent is MauiPanel mauiPanel ? mauiPanel.CachedChildren : (PlatformView.Parent as Panel)?.Children in ViewHandlerOfT.Windows.cs/ButtonExtensions.GetContent) that handles arbitrary Panel parents, not just MauiPanel. This code area was originally added in #30047 to fix #29930 (a different static-resource-style content-reuse COM exception) — since that scenario can involve content parented under any container type, this narrower ContentPanel/MauiPanel-only check risks reintroducing #29930 for content that requires a WrapperView, and this gap is not covered by the new Issue36298 test (which only exercises plain Label content with no Shadow/Clip).

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Handler Mapper and Property Patterns / Regression Prevention — Same incomplete parent-detection as ContentViewHandler.Windows.cs: only ContentPanel/MauiPanel parents are detached before reparenting; a WrapperView (or any other native Panel/ContentControl) parent is left untouched, so switching Border content that needs a platform container (Shadow/Clip/InputTransparent) between hosts can still throw the WinUI COM exception this PR is meant to fix. See the matching finding in ContentViewHandler.Windows.cs for the established general-purpose pattern (ViewHandlerOfT.Windows.cs.SetupContainer) that already handles arbitrary panel types and should be reused/mirrored here instead of this narrower type check.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Regression Prevention and Test Coverage — This PR changes both ContentViewHandler.Windows.cs and BorderHandler.Windows.cs, but the added UI test only exercises the ContentView path (via _contentHolder in the HostApp page); it never places the switched content inside a Border. The near-duplicate fix in BorderHandler.Windows.cs therefore ships with zero regression-test coverage — add a Border-based scenario (or parameterize this test) so a regression in the Border code path would actually be caught.

[MauiBot]

AI Review Summary

@devanathan-vaithiyanathan — new AI review results are available based on this last commit: 6aa094e. To request a fresh review after new comments or commits, comment /review rerun.

---

🗂️ Review Sessions — click to expand

🚦 Gate — Test Before & After Fix

Gate Result: ❌ FAILED

Platform: WINDOWS · Base: main · Merge base: 0395a53b

🩺 Test does not reproduce the bug — ran the same in both states (PASS without fix, PASS with fix). The repro test is not exercising the issue. Strengthen the test before reviewing the fix.

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🖥️ Issue36298 Issue36298	❌ PASS — 1456s	✅ PASS — 448s

🔴 Without fix — 🖥️ Issue36298: PASS ❌ · 1456s

(truncated to last 15,000 chars)

:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(33,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(34,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(35,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(19,56): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(20,57): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(14,57): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(15,57): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(8,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(9,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(10,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(11,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(12,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(13,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
    90 Warning(s)
    0 Error(s)

Time Elapsed 00:05:54.39
  Determining projects to restore...
  Restored D:\a\1\s\src\Controls\tests\CustomAttributes\Controls.CustomAttributes.csproj (in 671 ms).
  Restored D:\a\1\s\src\TestUtils\src\VisualTestUtils\VisualTestUtils.csproj (in 3 ms).
  Restored D:\a\1\s\src\TestUtils\src\VisualTestUtils.MagickNet\VisualTestUtils.MagickNet.csproj (in 5.3 sec).
  Restored D:\a\1\s\src\Controls\tests\TestCases.WinUI.Tests\Controls.TestCases.WinUI.Tests.csproj (in 7.78 sec).
  Restored D:\a\1\s\src\TestUtils\src\UITest.Core\UITest.Core.csproj (in 2 ms).
  Restored D:\a\1\s\src\TestUtils\src\UITest.Appium\UITest.Appium.csproj (in 2 ms).
  Restored D:\a\1\s\src\TestUtils\src\UITest.NUnit\UITest.NUnit.csproj (in 2 sec).
  Restored D:\a\1\s\src\TestUtils\src\UITest.Analyzers\UITest.Analyzers.csproj (in 4.75 sec).
  7 of 15 projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.100-ci+azdo.14657470
  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.100-ci+azdo.14657470
  Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0\Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.100-ci+azdo.14657470
  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.100-ci+azdo.14657470
  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.
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 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 7/14/2026 10:25:45 PM FixtureSetup for Issue36298(Windows)
>>>>> 7/14/2026 10:25:58 PM SwitchingContentPresenterContentShouldNotCrash Start
>>>>> 7/14/2026 10:26:02 PM SwitchingContentPresenterContentShouldNotCrash Stop
  Passed SwitchingContentPresenterContentShouldNotCrash [3 s]
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.31]   Discovered:  Controls.TestCases.WinUI.Tests
Results File: D:\a\1\s\CustomAgentLogsTmp\UITests\TestResults\Issue36298.trx

Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 36.4138 Seconds
>>> TRX_RESULT_FILE: D:\a\1\s\CustomAgentLogsTmp\UITests\TestResults\Issue36298.trx

🟢 With fix — 🖥️ Issue36298: PASS ✅ · 448s

(truncated to last 15,000 chars)

 respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(32,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(33,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(34,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(35,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(19,56): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(20,57): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(14,57): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\Styles\ShellStyles.xaml(15,57): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(8,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(9,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(10,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(11,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(12,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
Platform\Windows\TabbedPage\TabbedPageStyle.xaml(13,13): XamlCompiler warning WMC1510: Ensure the property path is trimming and AOT compatible by making use of 'Compiled Bindings (x:bind)' if possible or by specifying the 'x:DataType' directive with the respective binding data context and marking the type declaration with the 'WinRT.GeneratedBindableCustomProperty' attribute or the 'Microsoft.UI.Xaml.Data.Bindable' attribute. If you are unable to do either but can ensure the data type is attributed correctly, then you can also suppress the warning by specifying `x:SuppressXamlTrimWarnings=True` within the closest element. If not, the property path might be trimmed and will not be AOT compatible. [D:\a\1\s\src\Controls\src\Core\Controls.Core.csproj::TargetFramework=net10.0-windows10.0.19041.0]
    90 Warning(s)
    0 Error(s)

Time Elapsed 00:05:34.44
  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.100-ci+azdo.14657470
  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.100-ci+azdo.14657470
  Essentials -> D:\a\1\s\artifacts\bin\Essentials\Debug\net10.0\Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.100-ci+azdo.14657470
  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.100-ci+azdo.14657470
  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.
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 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 7/14/2026 10:48:14 PM FixtureSetup for Issue36298(Windows)
>>>>> 7/14/2026 10:48:27 PM SwitchingContentPresenterContentShouldNotCrash Start
>>>>> 7/14/2026 10:48:30 PM SwitchingContentPresenterContentShouldNotCrash Stop
  Passed SwitchingContentPresenterContentShouldNotCrash [3 s]
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.39]   Discovered:  Controls.TestCases.WinUI.Tests
Results File: D:\a\1\s\CustomAgentLogsTmp\UITests\TestResults\Issue36298.trx

Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 29.8437 Seconds
>>> TRX_RESULT_FILE: D:\a\1\s\CustomAgentLogsTmp\UITests\TestResults\Issue36298.trx

⚠️ Failure Details

• ❌ Issue36298 PASSED without fix (should fail) — tests don't catch the bug

📁 Fix files reverted (2 files)

• src/Core/src/Handlers/Border/BorderHandler.Windows.cs
• src/Core/src/Handlers/ContentView/ContentViewHandler.Windows.cs

---

📱 UI Tests — Layout,ViewBaseTests

Detected UI test categories: Layout,ViewBaseTests

✅ Deep UI tests — 307 passed, 0 failed across 2 categories on platform-pool agent (replaces in-process counts above).

🧪 UI Test Execution Results (deep, platform pool)

Category	Tests	Snapshot diffs
Layout	192/196 ✓	—
ViewBaseTests	115/115 ✓	—
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)

---

📋 Pre-Flight — Context & Validation

Issue: #36298 - [Windows] ContentPresenter throws ArgumentException when dynamically switching RefreshView or ScrollView content
PR: #36430 - [Windows]Fix ContentPresenter Throws System.ArgumentException When Dynamically Assigning RefreshView or ScrollView Content
Platforms Affected: Windows
Files Changed: 2 implementation, 2 test

Key Findings

• PR changes Windows ContentViewHandler and BorderHandler to detach reused platform views from old parents before assigning them to a new ContentPanel, aiming to avoid WinUI reparenting ArgumentException.
• Added UI test files for issue #36298, but the host page uses a ContentView holder instead of ContentPresenter; the supplied gate result says tests did not behave as expected, so the regression test is not currently a reliable guard.
• GitHub CLI is unauthenticated in this environment; public GitHub API and fetched PR refs were used for context. Required-check status could not be verified with gh pr checks --required.

Code Review Summary

Verdict: NEEDS_CHANGES
Confidence: low
Errors: 2 | Warnings: 0 | Suggestions: 0

Key code review findings:

• ✗ ContentViewHandler.Windows.cs and BorderHandler.Windows.cs detach only ContentPanel/MauiPanel parents; plain WinUI Panel parents remain possible through Windows handler infrastructure and can still throw on reparent.
• ✗ src/Controls/tests/TestCases.HostApp/Issues/Issue36298.cs uses ContentView rather than the reported ContentPresenter path; prior gate evidence says the test passes without the fix.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #36430	In ContentViewHandler/BorderHandler, convert content to platform view, remove it from old ContentPanel/MauiPanel parents, then assign/add it to the new ContentPanel; add UI test for repeated content switching.	❌ FAILED (Gate)	BorderHandler.Windows.cs, ContentViewHandler.Windows.cs, Issue36298.cs test files	Original PR; directionally addresses ContentPanel cached-child reuse but has unresolved coverage and parent-shape concerns.

---

🔬 Code Review — Deep Analysis

Code Review — PR #36430

Independent Assessment

What this changes: Windows ContentView/Border content updates now reparent existing platform views instead of disconnecting handlers, plus adds a UI regression test.
Inferred motivation: Avoid WinUI “already has an owner” exceptions when swapping ScrollView/RefreshView content.

Reconciliation with PR Narrative

Author claims: Fixes Windows ContentPresenter dynamic content crash by detaching platform views from old parents before reusing them.
Agreement/disagreement: Direction matches, but current code still misses some parent shapes and the test does not exercise ContentPresenter.

Prior Review Reconciliation

Prior ❌ Error Finding	Source	Status	Evidence
ContentPanel.Content = null no-op for direct CachedChildren content	MauiBot	✅ Fixed	Current code removes from ContentPanel.CachedChildren.
UI test passes without fix / does not reproduce bug	MauiBot	❌ Unresolved	Latest gate for 6aa094e still says PASS without/with fix; host uses ContentView at Issue36298.cs:28.
Missing plain WinUI Panel detach fallback	MauiBot	❌ Unresolved	Current code only handles ContentPanel/MauiPanel; ViewHandler<T>.SetupContainer uses (Parent as Panel)?.Children.

Blast Radius Assessment

• Runs for all instances: yes — Windows ContentView/Border handler content updates.
• Startup impact: no.
• Static/shared state: no.

CI Status

• Required-check result: gh pr checks --required unavailable due missing auth.
• Public API result: 34 check-runs; 33 success, 1 skipped; no failing/pending public checks.
• Classification: required-check coverage gap.
• Action taken: confidence capped low; no comments posted.

Findings

❌ Error — Windows detach still misses plain Panel parents

ContentViewHandler.Windows.cs:44 and duplicated BorderHandler.Windows.cs:45 only remove from ContentPanel/MauiPanel. Windows handler infrastructure can parent elements under plain WinUI Panel (ViewHandlerOfT.Windows.cs falls back to Panel.Children), so those elements can still throw on reparent.

❌ Error — Regression test does not exercise the reported ContentPresenter path

TestCases.HostApp/Issues/Issue36298.cs:28 uses a ContentView holder, while the issue is specifically dynamic ContentPresenter content. Prior gate evidence says the test passes without the fix, so it is not a reliable regression guard.

Failure-Mode Probing

• Plain Panel parent: not detached; reparent can still fail.
• ScrollView padding shim: now handled for ContentPanel.CachedChildren.
• Null content: sets Content = null, acceptable for tracked content.
• Handler disconnect/reconnect: no new subscriptions/static state.

Verdict: NEEDS_CHANGES

Confidence: low
Summary: The approach is directionally sound, but unresolved prior findings remain: missing plain Panel detachment and a non-reproducing regression test. Required-check status could not be verified via authenticated gh, though public checks are green/skipped.

---

🛠️ Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix	Centralized Windows FrameworkElement.RemoveFromParent plus ContentPanel.Content incoming detach; also routes ScrollView padding shim through ContentPanel.Content and fixes test to use ContentPresenter.	⚠️ BLOCKED (targeted builds passed; UI runner blocked)	7 files	Broadest coverage, but highest blast radius because it changes ScrollView padding-shim ownership.
2	try-fix	Narrow ContentPanel.SetContentWithReparenting helper used by ContentViewHandler/BorderHandler; fixes test to use ContentPresenter.	⚠️ BLOCKED (targeted builds passed; UI runner blocked)	5 files	Best alternative candidate: lower blast radius than #1, centralizes PR's duplicated logic, includes plain Panel fallback.
3	expert-review	Windows-only ContentPresenter preflight detach hook.	⏭️ NOT RUN (rejected before implementation)	0 files	Meaningfully different but inferior: only covers ContentPresenter transitions, not direct content-host assignment paths.
PR	PR #36430	Handler-local detach blocks in ContentViewHandler and BorderHandler; added UI test uses ContentView holder.	❌ FAILED (Gate)	4 files	Gate reported tests did not behave as expected; pre-flight found missing plain Panel fallback and test does not exercise ContentPresenter.

Cross-Pollination

Model	Round	New Ideas?	Details
maui-expert-reviewer	1	Yes	Candidate 1: shared Windows parent-removal infrastructure.
maui-expert-reviewer	2	Yes	Candidate 2: narrower opt-in ContentPanel helper avoiding ScrollView changes.
maui-expert-reviewer	3	No better primary fix	Candidate 3: ContentPresenter preflight hook, explicitly rejected as worse than Candidate 2.

Candidate Narratives

• try-fix-1/content.md: shared infrastructure approach; Core Windows and shared UI-test builds passed; full Windows UI run blocked by MAUI build-task environment timeout after one recovery attempt.
• try-fix-2/content.md: opt-in ContentPanel helper approach; Core Windows and shared UI-test builds passed; full Windows UI run blocked by the same build-task freshness error.
• try-fix-3/content.md: rejected design-only candidate; no implementation or tests.

Exhausted: Yes — explored shared infrastructure, narrow content-host helper, and ContentPresenter-layer preflight. Further variants would be trivial reshufflings of parent-detach location or narrower/worse coverage.
Selected Fix: Candidate #2 — best alternative on design grounds because it addresses the PR's duplicated logic and missing plain Panel fallback with less blast radius than Candidate #1. It is not demonstrably better by full gate execution because the Windows UI runner was environment-blocked; do not treat it as a passing replacement until the issue UI test runs successfully in a prepared MAUI build environment.

---

📝 Recommended PR Title & Description

Assessment: ✏️ Recommend updating — the winning fix adds a helper-based Windows reparenting path with arbitrary Panel fallback and Border coverage, while the current title/description only describe the raw ContentPresenter/ContentView-focused fix.

Recommended title

[Windows] ContentPresenter: Reparent RefreshView and ScrollView content safely

Recommended description

### Issue Details
A previous fix (#30047) called DisconnectHandler before clearing the old content. This cascaded into child handlers and broke WinUI's internal pointer event routing when views were orphaned from the visual tree.

### Description of Change
Get the incoming platform view first while the old panel is still live, detach it from any existing Windows parent, then assign it to the new content host. This avoids touching the internal handler hierarchy of views like ScrollView and RefreshView during a content switch.

The Windows content-host reparenting logic is centralized so both ContentViewHandler and BorderHandler use the same path. The detach step handles ContentPanel, MauiPanel, and arbitrary WinUI Panel parents such as WrapperView, matching existing Windows handler container patterns.

### Issues Fixed
Fixes #36298

**Tested the behavior in the following platforms.**
- [ ] Android
- [x] Windows
- [ ] iOS
- [ ] Mac

| Before  | After  |
|---------|--------|
| **Windows**<br> <video src="https://github.com/user-attachments/assets/10a349ed-eff4-4650-a0ca-274c77add95a" width="600" height="300"> | **Windows**<br> <video src="https://github.com/user-attachments/assets/1eec3997-5959-453d-b52e-1189d05656c8" width="600" height="300"> |

---

🏁 Report — Final Recommendation

Comparative Report - PR #36430

Candidate ranking

Rank	Candidate	Regression status	Assessment
1	pr-plus-reviewer	Not rerun; raw PR gate failed	Best design. Preserves the PR's handler-safe approach, adds the missing arbitrary WinUI Panel/WrapperView fallback, centralizes duplicated reparenting logic, and adds the missing Border-path coverage.
2	try-fix-2	Targeted builds passed; full Windows UI run blocked	Strongest STEP 5a alternative. It independently converged on the narrow ContentPanel.SetContentWithReparenting helper and plain Panel fallback, but its recorded test still lacks explicit Border coverage.
3	try-fix-1	Targeted builds passed; full Windows UI run blocked	More comprehensive infrastructure approach, but higher blast radius because it globally changes ContentPanel.Content behavior and routes ScrollViewHandler padding-shim ownership through the Content setter.
4	pr	Gate failed	Directionally correct because it avoids DisconnectHandler() and detaches before reparenting, but it misses non-MauiPanel parents and its added regression page uses ContentView rather than the reported ContentPresenter path.
5	try-fix-3	Not implemented / not run	Rejected design-only candidate. A ContentPresenter preflight hook is too narrow because it would miss direct Windows content-host assignment paths.

Why pr-plus-reviewer wins

The raw PR's core insight is sound: get the incoming platform view while the old visual tree is still live, detach it from its existing native parent, then assign it without disconnecting the managed handler hierarchy. The expert review found that the implementation is too narrow because Windows content may be parented by WrapperView : Grid or another WinUI Panel, not just ContentPanel/MauiPanel; pr-plus-reviewer fixes that while keeping the change opt-in to the affected content-host handlers.

try-fix-2 is the closest alternative and validates the same direction, but pr-plus-reviewer is preferred because it combines that helper-based approach with the expert review's required Border coverage. try-fix-1 is ranked lower because its broader ScrollView/content-panel behavior change creates unnecessary regression risk for a content-host reparenting bug. The submitted pr must rank below the non-failing candidates because the supplied gate result failed and the test did not exercise the reported ContentPresenter scenario.

Recommendation

Proceed with pr-plus-reviewer: apply the helper-based reparenting fix with a plain Panel fallback, update both ContentViewHandler and BorderHandler to use it, and strengthen Issue36298 so it covers ContentPresenter plus both affected handler paths.

---

🧭 Next Steps — review latest findings

No alternative fix was selected for this run. Review the session findings and CI results before merging.