Repository navigation
[iOS & Mac] Fix and Re-enable "Cells Do Not Leak" and "Handler Does Not Leak" Device Tests - #36698
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 36698Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 36698" |
|
Azure Pipelines: Successfully started running 1 pipeline(s). There may be pipelines that require an authorized user to comment /azp run to run. |
|
/azp run maui-pr-uitests , maui-pr-devicetests |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
|
/azp run maui-pr-uitests , maui-pr-devicetests |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
…ED red-X A gate that exceeds the 150-min safety cap is killed by AzDO and marked failed, which red-Xed the Review stage as if the PR's test verification genuinely FAILED (observed: build 14772346 / #36698 catalyst — 2 device tests x A/B exceeded 150m, 'The task has timed out'). A timeout is an infra/duration outcome, not a real test failure. Add continueOnError:true to the gate task. This is SAFE for genuine verdicts: the RunGate wrapper exits 0 and signals a real FAILED via the GateFailed output variable, which 'Check Review Result' turns into the red-X — so PASSED / FAILED / INCONCLUSIVE are all unchanged. continueOnError only affects the killed-on-timeout case, turning it into a non-blocking succeededWithIssues so the deep tests + expert review still deliver a summary (gate reported INCONCLUSIVE). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 15d2af20-e4ab-4e88-9011-cfbd83513bc0
This comment has been minimized.
This comment has been minimized.
CI Merge-Readiness: ❌ Not readyAnalyzed builds on head
UI tests — 27 failures, none on baselineCompared test-by-test against 5 recent
Notable failures:
The attribution is hard to argue with: this PR only touches The crashes, the NRE, and the Device tests — Android CoreCLR regression
That leg is green on 6/6 recent Test gateThe AI gate reported ❌ FAILED — the re-enabled tests passed both with and without the fix, so they do not currently reproduce #35985. Suggested next steps
🤖 Automated CI analysis — no approval or change request implied; a human review is still required. |
I have checked the review comments and validated the concerns raised through real device testing. The analysis correctly identified the core reuse regression. ClearSubviews() was kept in Unbind() as suggested, since removing it broke other tests that depend on proper native-view cleanup. Targeted reattachment was added in Bind() 's same-template branch (only when Superview is null ), matching the recommended "try-fix-2" approach. Two additional issues surfaced during device testing beyond the original review scope:
|
I have checked all 27 flagged failures ( CarouselView_CARV1_ios , CarouselView_ios , CollectionView_CV1_ios , CarouselView_mac ) including VerifyLoopChangeAtRuntimeShouldNotCrash , CarouselViewShouldScrollToRightPosition , ScrollCarouselViewAfterDispose , and CarouselViewShouldNotCrashOnSourceUpdateWithPageNavigation , root-caused them, applied fixes in TemplatedCell / ItemsViewController , and verified all pass on a real iOS 18.4 simulator. |
This comment has been minimized.
This comment has been minimized.
2db8b6a to
cfe2991
Compare
…ctionView, stepper and HybridWebView. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…ssion, NullReferenceException in cell measurement, and handler leak in the measurement-cell cache within TemplatedCell/ItemsViewController. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…achment in Bind() 's same-template branch, since Unbind() no longer detaches the native subview, preventing duplicate Auto Layout constraints from SetupPlatformView() accumulating across reuse cycles. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…uring conflict resolution. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…or-cleanup logic in ItemsViewController. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…add a _disposed re-entrancy guard, and release prior content in UseContent() before adopting the donor's. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…ot Leak" Device Tests (#36698) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes. ### Root cause The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection. A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue. ### Solution description The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test. **Note**: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control. Validated the behavior in the following platforms - [x] iOS - [x] Mac - [ ] Android - [ ] Windows ### Regression PR PR #35487 ### Issues Fixed Fixes #35985 ### Output Screenshot |Platform|Before|After| |--|--|--| |iOS|<video src="https://github.com/user-attachments/assets/9a59cc41-bf7b-4781-bffb-1d4eb6cd6da0"> |<video src="https://github.com/user-attachments/assets/dd527177-0022-4465-b7a1-303882f19f2e">| --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…r Does Not Leak" Device Tests (dotnet#36698)" This reverts commit 7f5d302.
…er Does Not Leak" Device Tests (#37672) <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue details: PR #36698 aimed to fix and re-enable the "Cells Do Not Leak" and "Handler Does Not Leak" device memory-leak tests on iOS and Mac. To achieve this, it changed `TemplatedCell` and `ItemsViewController` on iOS so that a cell's bound view is detached from the parent's logical children — and the cell's native subviews are cleared — during disposal, ensuring templated views are released deterministically instead of being permanently rooted. After this change merged, the `NavigateForwardWhenLooped` and `NavigateBackWhenLooped` CarouselView UI tests started failing on iOS. ### Description of changes: This reverts the changes introduced in PR #36698, which modified `TemplatedCell.cs` and `ItemsViewController.cs` on iOS/MacCatalyst to detach a cell's bound view from the parent's logical children and clear its native subviews during disposal. Reverting restores the prior cell disposal behavior, fixing the CarouselView looped-navigation regression (#37571). As a side effect, it also re-introduces the original memory-leak test failures that PR #36698 addressed. ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes #37571 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…ot Leak" Device Tests (#36698) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes. ### Root cause The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection. A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue. ### Solution description The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test. **Note**: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control. Validated the behavior in the following platforms - [x] iOS - [x] Mac - [ ] Android - [ ] Windows ### Regression PR PR #35487 ### Issues Fixed Fixes #35985 ### Output Screenshot |Platform|Before|After| |--|--|--| |iOS|<video src="https://github.com/user-attachments/assets/9a59cc41-bf7b-4781-bffb-1d4eb6cd6da0"> |<video src="https://github.com/user-attachments/assets/dd527177-0022-4465-b7a1-303882f19f2e">| --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…ot Leak" Device Tests (#36698) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes. The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection. A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue. The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test. **Note**: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control. Validated the behavior in the following platforms - [x] iOS - [x] Mac - [ ] Android - [ ] Windows PR #35487 Fixes #35985 |Platform|Before|After| |--|--|--| |iOS|<video src="https://github.com/user-attachments/assets/9a59cc41-bf7b-4781-bffb-1d4eb6cd6da0"> |<video src="https://github.com/user-attachments/assets/dd527177-0022-4465-b7a1-303882f19f2e">| --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…ot Leak" Device Tests (#36698) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes. ### Root cause The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection. A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue. ### Solution description The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test. **Note**: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control. Validated the behavior in the following platforms - [x] iOS - [x] Mac - [ ] Android - [ ] Windows ### Regression PR PR #35487 ### Issues Fixed Fixes #35985 ### Output Screenshot |Platform|Before|After| |--|--|--| |iOS|<video src="https://github.com/user-attachments/assets/9a59cc41-bf7b-4781-bffb-1d4eb6cd6da0"> |<video src="https://github.com/user-attachments/assets/dd527177-0022-4465-b7a1-303882f19f2e">| --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…er Does Not Leak" Device Tests (#37672) <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue details: PR #36698 aimed to fix and re-enable the "Cells Do Not Leak" and "Handler Does Not Leak" device memory-leak tests on iOS and Mac. To achieve this, it changed `TemplatedCell` and `ItemsViewController` on iOS so that a cell's bound view is detached from the parent's logical children — and the cell's native subviews are cleared — during disposal, ensuring templated views are released deterministically instead of being permanently rooted. After this change merged, the `NavigateForwardWhenLooped` and `NavigateBackWhenLooped` CarouselView UI tests started failing on iOS. ### Description of changes: This reverts the changes introduced in PR #36698, which modified `TemplatedCell.cs` and `ItemsViewController.cs` on iOS/MacCatalyst to detach a cell's bound view from the parent's logical children and clear its native subviews during disposal. Reverting restores the prior cell disposal behavior, fixing the CarouselView looped-navigation regression (#37571). As a side effect, it also re-introduces the original memory-leak test failures that PR #36698 addressed. ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes #37571 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…ot Leak" Device Tests (#36698) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes. ### Root cause The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection. A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue. ### Solution description The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test. **Note**: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control. Validated the behavior in the following platforms - [x] iOS - [x] Mac - [ ] Android - [ ] Windows ### Regression PR PR #35487 ### Issues Fixed Fixes #35985 ### Output Screenshot |Platform|Before|After| |--|--|--| |iOS|<video src="https://github.com/user-attachments/assets/9a59cc41-bf7b-4781-bffb-1d4eb6cd6da0"> |<video src="https://github.com/user-attachments/assets/dd527177-0022-4465-b7a1-303882f19f2e">| --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…ot Leak" Device Tests (#36698) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes. ### Root cause The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection. A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue. ### Solution description The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test. **Note**: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control. Validated the behavior in the following platforms - [x] iOS - [x] Mac - [ ] Android - [ ] Windows ### Regression PR PR #35487 ### Issues Fixed Fixes #35985 ### Output Screenshot |Platform|Before|After| |--|--|--| |iOS|<video src="https://github.com/user-attachments/assets/9a59cc41-bf7b-4781-bffb-1d4eb6cd6da0"> |<video src="https://github.com/user-attachments/assets/dd527177-0022-4465-b7a1-303882f19f2e">| --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…er Does Not Leak" Device Tests (#37672) <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue details: PR #36698 aimed to fix and re-enable the "Cells Do Not Leak" and "Handler Does Not Leak" device memory-leak tests on iOS and Mac. To achieve this, it changed `TemplatedCell` and `ItemsViewController` on iOS so that a cell's bound view is detached from the parent's logical children — and the cell's native subviews are cleared — during disposal, ensuring templated views are released deterministically instead of being permanently rooted. After this change merged, the `NavigateForwardWhenLooped` and `NavigateBackWhenLooped` CarouselView UI tests started failing on iOS. ### Description of changes: This reverts the changes introduced in PR #36698, which modified `TemplatedCell.cs` and `ItemsViewController.cs` on iOS/MacCatalyst to detach a cell's bound view from the parent's logical children and clear its native subviews during disposal. Reverting restores the prior cell disposal behavior, fixing the CarouselView looped-navigation regression (#37571). As a side effect, it also re-introduces the original memory-leak test failures that PR #36698 addressed. ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes #37571 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. -->
…ot Leak" Device Tests (#36698) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes. ### Root cause The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection. A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue. ### Solution description The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test. **Note**: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control. Validated the behavior in the following platforms - [x] iOS - [x] Mac - [ ] Android - [ ] Windows ### Regression PR PR #35487 ### Issues Fixed Fixes #35985 ### Output Screenshot |Platform|Before|After| |--|--|--| |iOS|<video src="https://github.com/user-attachments/assets/9a59cc41-bf7b-4781-bffb-1d4eb6cd6da0"> |<video src="https://github.com/user-attachments/assets/dd527177-0022-4465-b7a1-303882f19f2e">| --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
…ot Leak" Device Tests (#36698) <!-- Please let the below note in for people that find this PR --> > [!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](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! <!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### Issue Details The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes. ### Root cause The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection. A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue. ### Solution description The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test. **Note**: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control. Validated the behavior in the following platforms - [x] iOS - [x] Mac - [ ] Android - [ ] Windows ### Regression PR PR #35487 ### Issues Fixed Fixes #35985 ### Output Screenshot |Platform|Before|After| |--|--|--| |iOS|<video src="https://github.com/user-attachments/assets/9a59cc41-bf7b-4781-bffb-1d4eb6cd6da0"> |<video src="https://github.com/user-attachments/assets/dd527177-0022-4465-b7a1-303882f19f2e">| --------- Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 71612044-ad1f-454b-952b-004fa14c1744
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
The device memory leak validation tests began failing in the Candidate branch after the test-related changes introduced in PR #35487, which exposed actual memory leaks that were previously undetected. The regressions affected the Cells Do Not Leak and Handler Does Not Leak tests on Windows, the Cells Do Not Leak test on iOS, the Handler Does Not Leak test on iOS 26.0, and the Handler Does Not Leak test on macOS 26.0, indicating platform-specific memory leak issues that require fixes.
Root cause
The issue occurs because of a templated cell registering its bound view as a logical child of the parent items view when bound, but only removing that registration when the cell was rebound to a different template — never when a cell was simply bound once and then discarded without being recycled. This permanently rooted the templated view, and its subviews, in the parent's children list, preventing collection.
A related native-side reference on the cell's content view could independently keep the platform view (and bound view) reachable even if the logical-child link were cleared. The leak test itself also had a bug: it never released its local cell, handler, and control references before checking for garbage collection, which kept them rooted for the whole test and masked the production issue.
Solution description
The fix involves detaching the bound view from the parent's logical children and clearing the cell's native subviews during disposal, on the deterministic (non-finalizer) teardown path, so cleanup happens regardless of whether the cell was recycled, replaced, or simply discarded. It also involves correcting the test to explicitly tear down the cell and its owning control, then null out all local references, before verifying collection — since without this, the fix could never be exercised or proven in the test.
Note: The issue, "Handler Does Not Leak," was not reproduced in the Switch control. Therefore, the "Handler Doesn't Leak" test case has been re-enabled for the Switch control.
Validated the behavior in the following platforms
Regression PR
PR #35487
Issues Fixed
Fixes #35985
Output Screenshot
BeforeFix-CollectionView-MemoryLeak.iOS.1.1.mov
AfterFix-Cells.Do.not.leak.iOS.1.1.mov