/azp run

@PureWeen / @jsuarezruiz, We have analysed the test case (Issue1323Test) failure and found that the issue was caused by a button alignment-related issue. Previously, the button inside the page, which was added as a child within the TabbedPage, was not properly aligned in the center.

In this test case, the button was added directly as the content of the page without any additional properties. However, when the page was added as a child page within the TabbedPage, the button was not properly centered.

After the fix, the button inside the page, which was added as a child in the TabbedPage, was properly aligned in the center of the page.

The fix involved calling this.InvalidateMeasure(), which triggered a layout recalculation. This allowed the element within the TabbedPage to be measured and arranged correctly during the subsequent layout cycle.

As a result, the button was properly aligned in the center of the page. Previously, the layout measurements were not recalculated, which caused the button to be misaligned on the page.

Based on the current behavior after the fix, can we resave the current snapshot as the expected snapshot for this test case (Issue1323Test).

Button Alignment in the Page (Output image from the simple sample):

Page added as Child in the TabbedPge(Output image from the simple sample):

Testcase Image (Before Fix):

Current Testcase Image (After Fix):

/azp run

@BagavathiPerumal I've tried your pr with my app and it does appear to fix the issue, thanks!

@BagavathiPerumal I've tried your pr with my app and it does appear to fix the issue, thanks!

@Mark-NC001, Thank you so much for taking the time to test the PR with your app. We're truly glad to hear that it resolves the issue.

The test Issue1323Test related with TabbedPage and Navigation is failing on Windows. Small snapshot differences.

@jsuarezruiz, It looks expected behavior, as we already mentioned here, can we resave the current snapshot as the expected snapshot for this test case (Issue1323Test).

#26217 (comment)

/rebase

/azp run

Could be possible to include a test case for this changes?

In Appium, can minimize and maximize the Window (even change the Window size) using:

app.Driver.Manage().Window.Maximize();
app.Driver.Manage().Window.Maximize();

Let me know if can help in someway.

@jsuarezruiz, As suggested, I have tried recreating the test case using Appium but was unable to do so for this scenario. A NotImplementedException occurs when attempting to set the size value using testApp.Driver.Manage().Window.Size.

Exception details:

System.NotImplementedException: Unhandled endpoint: /session/2EDC486C-4A59-4E60-8C80-3EC866B72868/window/rect -- http://127.0.0.1:10100/ with parameters {
wildcards = (
"session/2EDC486C-4A59-4E60-8C80-3EC866B72868/window/rect"
);
}
at OpenQA.Selenium.WebDriver.UnpackAndThrowOnError(Response errorResponse, String commandToExecute)
at OpenQA.Selenium.WebDriver.ExecuteAsync(String driverCommandToExecute, Dictionary2 parameters) at OpenQA.Selenium.WebDriver.InternalExecute(String driverCommandToExecute, Dictionary2 parameters)
at OpenQA.Selenium.Window.set_Size(Size value)
at Microsoft.Maui.TestCases.Tests.Issues.Issue26103.VerifyTabbedPageScrollingBehavior() in /Users/bagavathi/Downloads/maui-fix-26103/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue26103.cs:line 25
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

Code:

using Microsoft.Maui.Controls.PlatformConfiguration;
using NUnit.Framework;
using UITest.Appium;
using UITest.Core;
namespace Microsoft.Maui.TestCases.Tests.Issues
{
    public class Issue26103 : _IssuesUITest
    {
        public Issue26103(TestDevice testDevice) : base(testDevice)
        {
        }
        public override string Issue => "TabbedPage - ScrollView not allowing scrolling when it should";
        [Test]
        [Category(UITestCategories.TabbedPage)]
        public void VerifyTabbedPageScrollingBehavior()
        {
            var testApp = (App as AppiumApp);
            if (testApp != null && testApp.Driver != null)
            {
                var originalWindowSize = testApp.Driver.Manage().Window.Size;
                testApp.Driver.Manage().Window.Size = new System.Drawing.Size(100, 200);
                testApp.WaitForElement("stackLayout1");
                VerifyScreenshot();
                testApp.Driver.Manage().Window.Size = originalWindowSize;
            }
        }
    }
}

I also tried creating a test case based on a button click to change the window size, but this approach did not reproduce the issue. The issue only occurs when resizing the window by dragging. Could you please share your suggestions on how to resolve it.

There are some TabbedPage Windows tests failing.

Issue1323Test Snapshot different than baseline: Issue1323Test.png (0.90% difference) (in red, the differences)

TestPageDoesntCrash

 at UITest.Appium.HelperExtensions.Tap(IUIElement element) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 302
  at UITest.Appium.HelperExtensions.Tap(IApp app, IQuery query) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 38
  at UITest.Appium.HelperExtensions.TapMoreButton(IApp app) in /_/src/TestUtils/src/UITest.Appium/HelperExtensions.cs:line 2261
  at Microsoft.Maui.TestCases.Tests.Issues.Issue2809.TestPageDoesntCrash() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/XFIssue/Issue2809.cs:line 19
  at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
  at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)

Could you review if are related with the changes?

@jsuarezruiz,

Case1: Issue1323Test

It looks expected behavior, as we already mentioned here, can we resave the current snapshot as the expected snapshot for this test case (Issue1323Test).

#26217 (comment)

Case2: TestPageDoesntCrash

I have verified that the test case failures are unrelated to the fix. This has been confirmed on a local machine.

/rebase

🚀 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 -- 26217

Or

• Run remotely in PowerShell:

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

🤖 AI Summary

📊 Expand Full Review — fc7ca15 · fix-26103-Resaved the test image.
🔍 Pre-Flight — Context & Validation
Issue: #26103 - TabbedPage - ScrollView not allowing scrolling when it should Related Issues: #11402 - TabbedPage App on resize hides page bottom content; #20028 - Grid overflows child ContentPage of parent TabbedPage on initial load and when resizing on Windows PR: #26217 - [Windows]Fix for TabbedPage - ScrollView not allowing scrolling when it should Platforms Affected: Windows Files Changed: 1 implementation, 6 test snapshot baselines

Key Findings

• All three linked issues describe the same Windows-only TabbedPage resize/layout problem: child page content shifts or overflows after window resize, causing lost bottom content or incorrect ScrollView extent.
• The PR changes src\Controls\src\Core\TabbedPage\TabbedPage.Windows.cs and resaves six WinUI snapshot baselines, but it does not add a new executable regression test for the resize behavior reviewers requested.
• Reviewer feedback specifically questioned whether Arrange() is necessary in the size-changed handler and repeatedly asked for a test that proves the fix.
• PR discussion indicates Issue1323Test snapshot drift was treated as expected fallout from the layout change, while another failing test (Issue2809) was reported as unrelated.
• A user comment on the PR confirms the branch appears to fix their real app, but pre-flight does not validate that claim.

Edge Cases / Discussion Notes

• The issue is triggered by window resizing on Windows; one report notes width changes can toggle whether the ScrollView reaches the bottom.
• Another related issue reports the broken layout can be present on initial load and then behave inconsistently as the window shrinks.
• The author reports Appium window resizing hit a NotImplementedException, which explains why the PR currently lacks a direct UI regression test.

Fix Candidates

Source Approach Test Result Files Changed Notes

PR PR #26217 In OnNavigationViewSizeChanged, call InvalidateMeasure() and then Arrange(_navigationView) so TabbedPage remeasures/rearranges after NavigationView size changes; resave affected WinUI snapshots PENDING (Gate) src\\Controls\\src\\Core\\TabbedPage\\TabbedPage.Windows.cs, snapshot baselines Original PR; reviewers requested proof that Arrange() is required and asked for a real test
🚦 Gate — Test Verification

Gate Result: SKIPPED

Platform: Windows Mode: Full Verification

• Tests in PR (TestCases.HostApp / TestCases.Shared.Tests): None added
• Tests FAIL without fix: N/A
• Tests PASS with fix: N/A

Notes:

• The PR modifies one implementation file and six Windows snapshot baselines, but it does not add a HostApp page or Shared UI test for the resize/scroll regression.
• Because no PR-added executable regression test exists, the required fail-without-fix / pass-with-fix verification could not be performed.
• Reviewer feedback on the PR explicitly requested a test, and the author noted Appium window resizing hit NotImplementedException, which appears to be why coverage is still missing.

🔧 Fix — Analysis & Comparison

Fix Candidates

Source Approach Test Result Files Changed Notes

1 try-fix (claude-opus-4.6) Invalidate _displayedPage on NavigationView size change and rely on the normal layout cycle instead of explicitly calling Arrange(_navigationView) PASS 1 file More targeted than the PR; directly addresses reviewer concern about Arrange()
2 try-fix (claude-sonnet-4.6) Call _navigationFrame?.UpdateLayout() on NavigationView size change to force a synchronous WinUI layout pass of the tab content subtree PASS 1 file Platform-level alternative; also removes the explicit Arrange() call
3 try-fix (gpt-5.3-codex) Clear cached _displayedPage and call UpdateCurrentPageContent() on NavigationView size change to refresh and remeasure the active tab content PASS 3 files during attempt Passing alternative, but it touched test files during the attempt to validate a new scenario
4 try-fix (gemini-3-pro-preview) Call _navigationFrame?.InvalidateMeasure() on NavigationView size change instead of invalidating the TabbedPage or arranging the NavigationView PASS 1 file Targeted content-frame invalidation also passes the proxy test
5 try-fix (claude-opus-4.6) Defer into the dispatcher and invalidate the nested ContentPresenter (InvalidateMeasure + InvalidateArrange) after NavigationView finishes resizing PASS 1 file Post-layout subtree invalidation also succeeds under the same proxy test
6 try-fix (claude-sonnet-4.6) Call _navigationView?.InvalidateArrange() on size change so native WinUI re-arranges the container and its children PASS 1 file Cleanest single-call WinUI-native alternative among the passing candidates
7 try-fix (gemini-3-pro-preview) Hook _navigationFrame.SizeChanged and react there instead of _navigationView.SizeChanged FAIL 1 file Failed the Windows proxy test with snapshot difference, suggesting the frame hook misses the real trigger
8 try-fix (claude-opus-4.6) Wrap the frame in a custom Grid host that invalidates the displayed page during arrange-size changes FAIL 1 file More invasive visual-tree rewrite caused a 0.89% snapshot difference
9 try-fix (gemini-3-pro-preview) Set _navigationView.HorizontalContentAlignment and .VerticalContentAlignment to Stretch and remove the size-change nudges PASS 1 file Declarative alternative, but root-cause confidence is lower than candidate 6
PR PR #26217 Invalidate the TabbedPage and explicitly call Arrange(_navigationView) in OnNavigationViewSizeChanged; resave affected WinUI snapshots NOT GATED 1 implementation file + 6 snapshot baselines No dedicated regression test was added, so Gate could not verify fail-without-fix / pass-with-fix

Cross-Pollination

Model Round New Ideas? Details
claude-opus-4.6 1 Yes Invalidate/arrange the ContentPresenter child in a deferred post-layout callback.
claude-sonnet-4.6 1 Yes Call _navigationView?.InvalidateArrange() on size change.
gpt-5.3-codex 1 No NO NEW IDEAS
gemini-3-pro-preview 1 Yes Hook _navigationFrame size changes instead of _navigationView and react to the actual content area size.
claude-opus-4.6 2 Yes Replace manual size-change nudges with a custom Grid host that naturally stretches the NavigationView/Frame.
claude-sonnet-4.6 2 No NO NEW IDEAS
gpt-5.3-codex 2 No NO NEW IDEAS
gemini-3-pro-preview 2 Yes Force _navigationView content alignments to Stretch.
claude-opus-4.6 3 Yes Custom LayoutPanel host that explicitly measures/arranges current page on every size change.
claude-sonnet-4.6 3 No NO NEW IDEAS
gpt-5.3-codex 3 No NO NEW IDEAS
gemini-3-pro-preview 3 No NO NEW IDEAS
Exhausted: No reached the 3-round cross-pollination limit with one remaining architectural rewrite idea untried. Selected Fix: Candidate #6 (_navigationView?.InvalidateArrange()) simplest passing WinUI-native fix among the tried alternatives, though confidence is limited because the PR still lacks a dedicated fail-without-fix / pass-with-fix regression test.

📋 Report — Final Recommendation

Final Recommendation: REQUEST CHANGES

Phase Status

Phase Status Notes
Pre-Flight COMPLETE Windows-only TabbedPage resize/layout bug; PR changes 1 implementation file and 6 WinUI snapshot baselines.
Gate SKIPPED PR adds no dedicated TestCases.HostApp / TestCases.Shared.Tests regression test, so fail-without-fix / pass-with-fix verification could not be run.
Try-Fix COMPLETE 9 attempts run, 7 passing and 2 failing; multiple materially different alternatives passed the current Windows proxy test.
Report COMPLETE

Summary

The PR is addressing a real Windows TabbedPage resize bug, but it still should not be approved in its current form. The main blocker is test quality: there is no dedicated regression test for the resize/scroll scenario reviewers asked for, so the gate had to be skipped. In try-fix, seven materially different alternatives passed the available proxy test (Issue1323Test), which means the current validation is too weak to show that the PR's specific InvalidateMeasure() + Arrange() fix is necessary or best.

Root Cause

The underlying problem appears to be stale layout propagation after NavigationView size changes on Windows TabbedPage hosting. Child content (especially the frame/ScrollView subtree) is not consistently remeasured or rearranged when the container resizes, causing clipped bottom content or incorrect scroll extent after window resize.

Fix Quality

The PR fix is plausible, but it is heavier than necessary and still unproven. Reviewer feedback specifically questioned the explicit Arrange() call, and try-fix found cleaner passing alternatives such as candidate #6 (_navigationView?.InvalidateArrange()) and candidate #1 (_displayedPage?.InvalidateMeasure()). Because no dedicated regression test exists, I do not have enough evidence to recommend the PR's current implementation over those simpler options. I would request changes to add a real reproducible regression test for the resize behavior and then re-evaluate the implementation choice against that stronger test.

📋 Expand PR Finalization Review

I’ve reviewed and updated the changes based on the latest findings. Specifically:

• Verified the AI-suggested fix on the Windows platform and confirmed that it does not resolve the issue
• Confirmed that the suggested code changes do not address the root cause of the problem
• Retained the existing implementation, as the AI-proposed modifications are not effective in resolving the issue
• Checked the possibilities to add the testcase for the windows resizing behavior. However, unable to add the testcase for the windows resizing behavior.
• Ensured the findings are aligned with the current PR status and reviewer expectations
• The InvalidateMeasure() + immediate Arrange(...) pattern in OnNavigationViewSizeChanged() requires justification, as it is an uncommon layout approach and lacks test validation; however, Arrange() is currently necessary to prevent failures in ChangingToNewMauiContextDoesntCrash.
• Updated the description and title based on the changes made in the PR.

/azp run maui-pr-uitests

Please review the ai's summary :)

I have reviewed the AI summary. The Arrange() call in the NavigationView.SizeChanged method is necessary to prevent test failures. Without this change, the ChangingToNewMauiContextDoesntCrash test consistently fails with a TimeoutException.

/rebase

🏷️ Test Categories for Regression Detection

No [Category] attributes were found in added test lines, but the changed source file (TabbedPage.Windows.cs) and updated Windows snapshot images indicate TabbedPage is the affected area. Categories were inferred from the source path.

UI Test Categories

Pipeline filter: TabbedPage

Device Test Categories

Recommendation: Run device tests: Yes — Windows-specific TabbedPage platform handler code changed.

🚀 Run Targeted Tests on Existing Pipelines

Both maui-pr-uitests and maui-pr-devicetests now support category filtering parameters. To run only the relevant tests for this PR:

UI Tests — trigger maui-pr-uitests with:

Parameter: uiTestCategories = TabbedPage

Device Tests — trigger maui-pr-devicetests with:

Parameter: deviceTestCategories = TabbedPage

When triggered without parameters (e.g., by normal PR push), all categories run as usual.

ℹ️ Categories are detected from [Category()] attributes in the diff and inferred from changed source file paths.

🏷️ Category detection by Detect Test Categories for Regression Detection

🚦 Gate — Test Before and After Fix

👋 @BagavathiPerumal — new gate results are available. Please review the latest session below.

@copilot write tests for this PR

@copilot write tests for this PR

🤖 AI Summary

👋 @BagavathiPerumal — new AI review results are available. Please review the latest session below.

void OnNavigationViewSizeChanged(object sender, SizeChangedEventArgs e)
{
    if (_navigationView != null)
        this.InvalidateMeasure();
}

🤖 AI Summary

👋 @BagavathiPerumal — new AI review results are available. Please review the latest session below.

📊 Review Session — 4eb69f6 · fix-26103-Resaved the test image. · 2026-04-12 15:56 UTC
🔍 Pre-Flight — Context & Validation
Issue: #26103 - TabbedPage - ScrollView not allowing scrolling when it should Related Issues: #11402 - TabbedPage app on resize hides page bottom content; #20028 - TabbedPage layout misalignment on window resize PR: #26217 - [Windows] TabbedPage: Refresh layout when NavigationView size changes Platforms Affected: Windows (fix), snapshot updates affect Windows UI tests Files Changed: 1 implementation, 6 test snapshots (no new tests added) Gate Result: ⚠️ SKIPPED — no tests detected

Key Findings

• Root cause: OnNavigationViewSizeChanged only called this.Arrange(_navigationView) without first invalidating the measure cache, so the layout pass used stale measurements after a window resize, causing scroll content to be clipped.
• Fix: The PR adds this.InvalidateMeasure() before the existing this.Arrange(_navigationView) call inside the null-guard block.
• Concern from reviewer (PureWeen): Asked whether Arrange() is even needed and whether InvalidateMeasure() alone suffices. The PR author claims removing Arrange() causes the ChangingToNewMauiContextDoesntCrash test to time out. This claim has not been independently verified.
• Comment from inline reviewer (jsuarezruiz): Suggested adding a test using Appium Window.Maximize()/Window.Minimize() to reproduce. Author attempted but could not successfully reproduce via Appium test.
• Reporter confirmed fix works: Issue reporter (Mark-NC001) tested PR and confirmed ScrollView now scrolls to the bottom correctly.
• No new tests added: PR author argues window resize is not automatable. Gate skipped since no tests present.
• Snapshot changes: 6 TabbedPage Windows snapshot baselines were updated because the layout is now more correct (items better aligned). This is an expected side-effect of the fix.
• Inline comments: One unresolved review thread — PureWeen's question about whether Arrange() is still needed.
• Prior agent reviews: None (only an AI summary posted by the PR author, not an agent review).

Fix Candidates

Source Approach Test Result Files Changed Notes

PR PR #26217 Add InvalidateMeasure() before existing Arrange(_navigationView) call in OnNavigationViewSizeChanged ⚠️ SKIPPED (no tests) TabbedPage.Windows.cs + 6 snapshots Original PR; Arrange() kept to prevent test timeout per author
🔧 Fix — Analysis & Comparison

Fix Candidates

Source Approach Test Result Files Changed Notes

1 try-fix (claude-opus-4.6) Replace this.Arrange(_navigationView) with _navigationView.InvalidateMeasure() to let WinUI's layout cycle handle re-arrangement ⚠️ BLOCKED TabbedPage.Windows.cs Compiles cleanly, unit tests pass; device tests unavailable
2 try-fix (claude-sonnet-4.6) Directly measure+arrange _displayedPage using _navigationFrame.ActualWidth/Height (content area dimensions) ⚠️ BLOCKED TabbedPage.Windows.cs Compiles cleanly; device tests unavailable
3 try-fix (gpt-5.3-codex) Dual invalidation (InvalidateMeasure + InvalidateArrange) on both this and _navigationView, no explicit Arrange() ⚠️ BLOCKED TabbedPage.Windows.cs Compiles cleanly; device tests unavailable
4 try-fix (gpt-5.4) _displayedPage.InvalidateMeasure() + platform view fallback invalidation ⚠️ BLOCKED TabbedPage.Windows.cs Compiles cleanly; device tests unavailable
PR PR #26217 Add this.InvalidateMeasure() before existing this.Arrange(_navigationView) call in OnNavigationViewSizeChanged ⚠️ SKIPPED (Gate) TabbedPage.Windows.cs + 6 snapshots Original PR

Cross-Pollination

Model Round New Ideas? Details
claude-opus-4.6 2 Yes Key insight: this.Arrange(_navigationView) uses FrameworkElementExtensions.Arrange (line 184) which has a guard: if (!view.Frame.Equals(rect)). This means if MAUI Frame already matches the current NavigationView dimensions, the arrange is silently skipped. New ideas: (1) Bypass guard with e.NewSize directly calling VisualElement.Arrange(Rect) unconditionally; (2) Defer layout to next dispatcher tick via DispatcherQueue.TryEnqueue; (3) Subscribe to _navigationFrame.SizeChanged instead; (4) Use WinUI _navigationView.UpdateLayout()
Exhausted: Yes — all 4 models + cross-pollination completed

Key Infrastructure Finding: All Windows device tests (including ChangingToNewMauiContextDoesntCrash) blocked with WindowsAppSDKSelfContained requires a supported Windows architecture. Unit tests pass for all approaches.

Selected Fix: PR #26217 — No attempt could be validated over the PR's fix due to device test infrastructure unavailability. The PR's approach (InvalidateMeasure() + Arrange()) is the most tested fix (reporter confirmed working). However, PureWeen's concern about the Arrange() call inside SizeChanged remains unresolved. The cross-pollination insight about the FrameworkElementExtensions.Arrange guard (line 184) is relevant — if the guard is the real root cause, bypassing it with e.NewSize might be cleaner.

📋 Report — Final Recommendation

⚠️ Final Recommendation: REQUEST CHANGES

Phase Status

Phase Status Notes
Pre-Flight ✅ COMPLETE Issue #26103 (Windows TabbedPage ScrollView clipping on resize) + related #11402, #20028
Gate ⚠️ SKIPPED No tests detected in PR
Try-Fix ⚠️ BLOCKED 4 attempts, 0 passing — Windows device test infrastructure unavailable (WindowsAppSDKSelfContained requires a supported Windows architecture)
Report ✅ COMPLETE
Selected Fix: PR (no alternative could be validated)

Summary

PR #26217 fixes a Windows-only layout bug where TabbedPage containing a ScrollView fails to correctly update its layout after window resize. The fix adds this.InvalidateMeasure() before the existing this.Arrange(_navigationView) call in OnNavigationViewSizeChanged. This is a 5-line change to TabbedPage.Windows.cs plus 6 updated snapshot baselines.

The fix is confirmed working by the issue reporter. However, there is an unresolved reviewer concern from PureWeen about whether the Arrange() call inside SizeChanged is necessary and correct, and no new automated tests were added.

Root Cause

When the window is resized, the WinUI NavigationView.SizeChanged event fires. The original handler called this.Arrange(_navigationView), which uses the FrameworkElementExtensions.Arrange(IView, FrameworkElement) extension method (defined in FrameworkElementExtensions.cs:184). This extension method:

1. Builds a Rect(0, 0, frameworkElement.ActualWidth, frameworkElement.ActualHeight) from current NavigationView dimensions
2. Only calls view.Arrange(rect) if !view.Frame.Equals(rect) (guard to prevent redundant arranges)

The bug: view.Arrange(rect) does NOT call InvalidateMeasure() first. So when the layout pass runs, the MAUI measure cache still contains stale sizes from before the resize. The ScrollView child's DesiredSize is never re-measured with the new window dimensions, causing clipping.

The PR's fix correctly adds this.InvalidateMeasure() before this.Arrange() so that stale measurements are discarded before the arrangement pass runs.

Fix Quality

Strengths:

• ✅ Fix is minimal and targeted (5 lines changed in one method)
• ✅ Addresses the correct root cause (stale measure cache)
• ✅ Confirmed working by issue reporter (Mark-NC001)
• ✅ Snapshot updates are expected and correct (layout is now more accurate)

Concerns requiring author response:

1. ❓ Is this.Arrange(_navigationView) still needed? — PureWeen asked whether InvalidateMeasure() alone suffices. The PR author claims removing Arrange() causes ChangingToNewMauiContextDoesntCrash device test to time out. This claim should be independently verified. Calling Arrange() inside a SizeChanged handler of the same view is architecturally unusual and could cause layout re-entrancy issues.
2. 🔍 Consider bypassing the extension method guard — The FrameworkElementExtensions.Arrange extension has a frame-equality guard. If the new size matches the MAUI Frame (e.g., when window is restored to its original size), the arrange is silently skipped. A more robust approach may be: this.InvalidateMeasure(); this.Arrange(new Graphics.Rect(0, 0, e.NewSize.Width, e.NewSize.Height)); using e.NewSize from the event args to bypass the guard unconditionally.
3. ⚠️ No new tests — The Gate was skipped because no tests were added. The reviewer (jsuarezruiz) suggested using Appium's app.Driver.Manage().Window.Maximize() / Minimize() to test window resize behavior. This is technically feasible and should be explored.
4. 🧹 Inline code comments — The two inline comments added (// Ensure TabbedPage layout responds to NavigationView size changes, // Complete layout to fix frame dimensions) do not add significant clarity over the code itself and should follow the repo convention of minimal comments.

Recommendation Details

The fix is functionally correct based on reporter confirmation and code analysis. However, the open reviewer question about Arrange() necessity plus the absence of tests leads to a REQUEST CHANGES recommendation. The author should:

1. Address PureWeen's concern about Arrange() vs InvalidateMeasure() alone with a reproducible test or CI evidence
2. Consider using e.NewSize to bypass the extension guard for robustness
3. Explore adding a window-resize UI test as jsuarezruiz suggested
4. Remove or simplify the inline code comments to match repo style

I’ve reviewed and updated the changes based on the latest findings. Specifically:

• The reason for using Arrange(_navigationView) has already been updated in the comment. It is currently required to prevent failures in ChangingToNewMauiContextDoesntCrash.
• The code has been updated based on the suggestion to bypass the extension method guard.
• The reason for not adding a test case for this fix has already been mentioned in the PR template and also clarified in the comments.
• Inline code comments have been removed to align with the repository style.