[iOS] Fixed Shell navigation on search handler suggestion selection

[SubhikshaSf4851]

Root Cause :

Navigation fails because UISearchController was dismissed before ItemSelected was called, triggering a UIKit transition that deactivates the Shell navigation context and prevents the navigation from completing

Description of Change :

Changed the order in OnSearchItemSelected in ShellPageRendererTracker.cs to call ItemSelected before deactivating the search controller for correct event handling.

Issues Fixed

Fixes #33356

Tested the behavior in the following platforms

• Windows
• Android
• iOS
• Mac

Before Issue Fix	After Issue Fix
Screen.Recording.2026-01-07.at.11.49.23.mov	Screen.Recording.2026-01-07.at.11.48.07.mov

[Copilot]

Pull request overview

This PR fixes an iOS-specific issue where Shell navigation fails when selecting items from SearchHandler suggestions. The root cause is that dismissing the UISearchController before calling ItemSelected triggers a UIKit transition that deactivates the Shell navigation context, preventing navigation from completing.

Key Changes:

• Reordered operations in OnSearchItemSelected to call ItemSelected before setting _searchController.Active = false
• Added comprehensive UI test coverage for SearchHandler navigation behavior

Reviewed changes

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

File	Description
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellPageRendererTracker.cs	Swapped the order of operations in OnSearchItemSelected to fix the navigation timing issue
src/Controls/tests/TestCases.HostApp/Issues/Issue33356.cs	Added HostApp test page with Shell, SearchHandler, and navigation structure to reproduce the issue
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33356.cs	Added UI test that verifies navigation works from both SearchHandler results and CollectionView

[kubaflo]

PR Review: #33406 - [iOS] Fixed Shell navigation on search handler suggestion selection

Date: 2026-01-07 | Issue: #33356 | PR: #33406

⏳ Status: COMPLETE

Phase	Status
Pre-Flight	✅ COMPLETE
🧪 Tests	✅ COMPLETE
🚦 Gate	✅ PASSED
🔧 Fix	✅ COMPLETE
📋 Report	✅ COMPLETE

---

📋 Issue Summary

Issue #33356: [iOS] Clicking on search suggestions fails to navigate to detail page correctly

Root Cause: Navigation fails because UISearchController was dismissed before ItemSelected was called, triggering a UIKit transition that deactivates the Shell navigation context and prevents navigation from completing.

Steps to Reproduce:

1. Open the MAUI Sample App: https://github.com/dotnet/maui-samples/tree/main/10.0/Fundamentals/Shell/Xaminals
2. Deploy to iPhone 17 Pro iOS 26.2 simulator
3. Put focus on the search box
4. Type 'b' in the search box
5. Click on 'Bengal' search suggestion
6. Expected: Navigates to Bengal cat detail page
7. Actual: No navigation happens

Platforms Affected:

• Android
• iOS
• Windows
• MacCatalyst

Regression: Yes - This is a regression from version 9.0.90 according to issue validation comment.

Issue Labels: t/bug, platform/ios, s/verified, s/triaged, i/regression, shell-search-handler, regressed-in-9.0.90

📁 Files Changed

File	Type	Changes
src/Controls/src/Core/Compatibility/Handlers/Shell/iOS/ShellPageRendererTracker.cs	Fix	2 lines (swapped order)
src/Controls/tests/TestCases.HostApp/Issues/Issue33356.cs	Test (HostApp)	+261 lines
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33356.cs	Test (NUnit)	+46 lines

Fix Classification: iOS-specific Shell navigation bug (platform handler)

Test Type: UI Tests (Shell category)

💬 PR Discussion Summary

Key Comments:

• Issue validated by TamilarasanSF4853 (Syncfusion partner) in VS Code 1.107.1 with MAUI versions 9.0.0 through 10.0.20
• Reproducible on iOS platform
• Note: "Issue 2" (empty page on back navigation) is reproducible from version 9.0.90

Reviewer Feedback:

• No inline review comments yet (PR just opened)

Disagreements to Investigate:

File:Line	Reviewer Says	Author Says	Status
N/A	N/A	N/A	No disagreements yet

Author Uncertainty:

• None noted in PR description

🧪 Tests

Status: ✅ COMPLETE

• PR includes UI tests
• Tests reproduce the issue (verified - timeout without fix)
• Tests follow naming convention (Issue33356)

Test Files:

• HostApp: src/Controls/tests/TestCases.HostApp/Issues/Issue33356.cs
• NUnit: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33356.cs

Test Description:

• Creates a Shell app with search handler
• Tests navigation from search suggestion selection
• Tests navigation from collection view item selection
• Verifies back navigation works correctly

🚦 Gate - Test Verification

Status: ✅ PASSED

• Tests FAIL without fix (bug reproduced - timeout waiting for element)
• Tests PASS with fix (fix validated - navigation successful)

Result:

WITHOUT FIX: FAILED - System.TimeoutException: Timed out waiting for element "Issue33356CatNameLabel"
WITH FIX: PASSED - All 1 tests passed in 21.73 seconds

Verification Details:

• Platform tested: iOS (iPhone simulator iOS 18.5)
• Test duration without fix: 18s (timeout)
• Test duration with fix: 5s (successful navigation)
• The fix correctly enables navigation from search suggestions

🔧 Fix Candidates

Status: ✅ COMPLETE

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33406	Swap order: Call ItemSelected BEFORE deactivating search controller	✅ PASS (Gate)	ShellPageRendererTracker.cs (2 lines)	Original PR - simple ordering fix

Exhausted: No (PR fix is correct and sufficient)
Selected Fix: PR #33406 - Validated and recommended

---

🔍 Root Cause Analysis

Problem: When a user selects a search suggestion in Shell's SearchHandler on iOS, the navigation fails silently.

Root Cause: The original code dismissed the UISearchController (Active = false) before calling ItemSelected. This triggers a UIKit transition that deactivates the Shell navigation context, preventing the subsequent navigation from completing.

Why This Matters:

• UIKit's UISearchController.Active = false initiates a dismiss animation
• During this dismiss, the navigation context becomes invalid
• The ItemSelected handler then tries to navigate in an invalid context
• Result: Navigation request is ignored

Fix: Simply swap the order - call ItemSelected first (while navigation context is still valid), then dismiss the search controller.

Code Change:

void OnSearchItemSelected(object? sender, object e)
{
    if (_searchController is null)
        return;

-   _searchController.Active = false;
    (SearchHandler as ISearchHandlerController)?.ItemSelected(e);
+   _searchController.Active = false;
}

Why This Fix Works:

1. ItemSelected is called while UISearchController is still active and navigation context is valid
2. Navigation request is processed successfully
3. Search controller is dismissed after navigation completes
4. UIKit transition doesn't interfere with Shell navigation

✅ Fix Validation

Verification Results:

• ✅ Tests FAIL without fix (reproduces bug)
• ✅ Tests PASS with fix (validates solution)
• ✅ Fix is minimal (2 lines swapped)
• ✅ Fix is iOS-specific (correct platform targeting)
• ✅ No side effects identified

Alternative Approaches Considered:

1. Delay dismissal - Could use async/await to delay Active = false, but adds complexity
2. Navigation first, then dismiss - This is exactly what the PR does ✅
3. Cancel dismiss animation - Would require UIKit animation manipulation, unnecessary complexity

PR Fix is Optimal: Simple, direct, addresses root cause without side effects.

📊 Quality Assessment

Aspect	Rating	Notes
Fix Correctness	✅ Excellent	Addresses root cause directly
Test Quality	✅ Excellent	Comprehensive UI test with proper reproduction
Code Impact	✅ Minimal	Only 2 lines changed
Platform Specificity	✅ Correct	iOS-only fix in iOS-specific file
Regression Risk	✅ Low	Simple ordering change, well-tested
Documentation	✅ Good	PR description explains root cause

Strengths:

• ✅ Minimal, surgical fix
• ✅ Comprehensive test coverage
• ✅ Clear root cause explanation in PR
• ✅ Validated by Gate (tests fail without fix, pass with fix)

No Issues Found

---

✅ Final Recommendation: APPROVE

Verdict: This PR correctly fixes the iOS Shell navigation bug with a minimal, well-tested solution.

Summary:

• Root cause: UISearchController dismiss was deactivating navigation context
• Fix: Call ItemSelected before dismissing search controller
• Validation: Tests confirm fix works, no side effects identified
• Quality: Excellent test coverage, minimal code change

Recommendation: ✅ APPROVE - Ready to merge

Next Step: Verify tests compile and reproduce the issue (Phase 2: Tests)

[PureWeen]

/rebase

[PureWeen]

UI Test Code Style Feedback

The fix looks correct, but the UI test has inline #if directives that should be refactored for code cleanliness.

Issue

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue33356.cs

The test uses inline #if ANDROID ... #else ... blocks (lines 9-13 and 28-34). Per our UI test guidelines, platform-specific behavior should be hidden behind extension methods to keep test code readable.

Suggested Fix

Move the platform-specific tapping logic to an extension method:

// In UtilExtensions.cs (or a new extension class)
public static void TapFirstSearchResult(this IApp app, UITestContextBase context, IUIElement searchHandler)
{
    if (context.Device == TestDevice.Android)
    {
        // Android does not support selecting elements in SearchHandler results
        var y = searchHandler.GetRect().Y + searchHandler.GetRect().Height;
        app.TapCoordinates(searchHandler.GetRect().X + 10, y + 10);
    }
    else
    {
        var searchResults = app.FindElements("SearchResultName");
        searchResults.First().Tap();
    }
}

Then the test becomes cleaner:

var searchHandler = App.GetShellSearchHandler();
searchHandler.Tap();
searchHandler.SendKeys("A");
App.TapFirstSearchResult(this, searchHandler);  // Clean!

Similarly, the BackButtonIdentifier constant could be handled via an extension method or the existing TapBackArrow could be updated to handle the platform difference internally.

---

Note: This is a code style request only. The actual fix (swapping ItemSelected() before Active = false) looks correct.

[SubhikshaSf4851]

@PureWeen As suggested I have added the extension method