[iOS] Added support for large titles in Shell

[kubaflo]

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!

Description of Change

Introduces the UpdateLargeTitles method to manage large title display modes for navigation bars in ShellItemRenderer. This ensures that the large title preference is updated when the displayed page changes or when the view lays out subviews, aligning with iOS-specific platform configurations.

Issues Fixed

Fixes #12156

[dotnet-policy-service]

Hey there @@kubaflo! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull Request Overview

This PR introduces web resource request interception capabilities to the BlazorWebView component and includes extensive localization updates for .NET MAUI template strings. The primary purpose is to enable applications to intercept and customize web resource requests within BlazorWebView controls, while also updating localized template descriptions across multiple languages.

• Adds web resource request interception functionality to BlazorWebView
• Updates BlazorWebView to implement IWebRequestInterceptingWebView interface
• Includes comprehensive localization updates for template strings in multiple languages

Reviewed Changes

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

Show a summary per file

File	Description
src/BlazorWebView/src/Maui/IBlazorWebView.cs	Extended interface to inherit from IWebRequestInterceptingWebView
src/BlazorWebView/src/Maui/BlazorWebView.cs	Added WebResourceRequested event and implementation
src/BlazorWebView/src/Maui/Android/WebKitWebViewClient.cs	Enhanced request interception logic with improved logging
src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs	Updated Android WebView integration with namespace changes
src/BlazorWebView/src/Maui/PublicAPI/*.txt	Added new public API surface for WebResourceRequested event
loc//src/Templates/src/templates/	Updated localized template strings across multiple languages

[jfversluis]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[jfversluis]

/rebase

[jfversluis]

/rebase

[jfversluis]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[kubaflo]

# PR Review: #32081 - [iOS] Added support for large titles in Shell

PR: #32081
Issue: #12156
Reviewer: GitHub Copilot PR Reviewer
Review Date: 2025-11-20

Summary

PR #32081 implements iOS large navigation bar titles in Shell by adding UpdateLargeTitles() to ShellItemRenderer.cs. The implementation correctly maps .NET MAUI's LargeTitleDisplayMode to iOS UINavigationItemLargeTitleDisplayMode.

Status: ✅ Excellent implementation with minor cosmetic cleanup suggested

Core implementation: ✅ Solid - proper null checks, iOS version guard, correct enum mapping, appropriate lifecycle hooks
Test coverage: ✅ Well-structured with screenshot verification, has minor redundancy in preprocessor directive

---

Code Review

✅ Positive Aspects

1. Correct iOS version check

   • Uses OperatingSystem.IsIOSVersionAtLeast(11) (large titles introduced in iOS 11)
   • Prevents crashes on older iOS versions

2. Proper null safety

   • Checks page is null before proceeding
   • Checks navigationController and top before accessing

3. Appropriate lifecycle hooks

   • Called in OnDisplayedPageChanged() when page changes
   • Called in ViewWillLayoutSubviews() to ensure state consistency

4. Correct enum mapping

   LargeTitleDisplayMode.Always => UINavigationItemLargeTitleDisplayMode.Always,
   LargeTitleDisplayMode.Automatic => UINavigationItemLargeTitleDisplayMode.Automatic,
   _ => UINavigationItemLargeTitleDisplayMode.Never

5. Sets both required properties

   • NavigationBar.PrefersLargeTitles (enables feature)
   • NavigationItem.LargeTitleDisplayMode (per-page control)

6. Follows existing patterns

   • Mirrors UpdateTabBarHidden() implementation
   • Consistent with Shell handler architecture

---

🟡 Minor Issues

1. Redundant Conditional Compilation

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue12156.cs
Line: 1

Issue:

#if TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_WINDOWS

TEST_FAILS_ON_ANDROID appears twice - this is redundant but harmless.

How it works: The test project system defines constants for platforms where tests SHOULD NOT run:

• iOS.Tests defines: TEST_FAILS_ON_ANDROID, TEST_FAILS_ON_WINDOWS, TEST_FAILS_ON_CATALYST
• Android.Tests defines: TEST_FAILS_ON_IOS, TEST_FAILS_ON_WINDOWS, TEST_FAILS_ON_CATALYST

So this condition:

• iOS tests: TRUE && TRUE && TRUE = TRUE → test runs ✅
• Android tests: FALSE && FALSE && TRUE = FALSE → test skipped ✅
• Windows tests: FALSE && FALSE && FALSE = FALSE → test skipped ✅

Fix (optional cleanup):

#if TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_WINDOWS  // Remove duplicate

Impact: LOW - Code compiles and runs correctly, just has a cosmetic redundancy

---

🟡 Suggestions for Improvement

1. Missing Dynamic Property Change Handling

Current behavior: UpdateLargeTitles() is only called when:

• Displayed page changes (OnDisplayedPageChanged)
• View lays out subviews (ViewWillLayoutSubviews)

Gap: If a user changes Page.LargeTitleDisplay property dynamically at runtime (e.g., in response to user action), the navigation bar won't update.

Comparison: OnDisplayedPagePropertyChanged only listens for Shell.TabBarIsVisibleProperty:

void OnDisplayedPagePropertyChanged(object sender, PropertyChangedEventArgs e)
{
    if (e.PropertyName == Shell.TabBarIsVisibleProperty.PropertyName)
        UpdateTabBarHidden();
    // Missing: Check for LargeTitleDisplay property changes
}

Suggested improvement:

void OnDisplayedPagePropertyChanged(object sender, PropertyChangedEventArgs e)
{
    if (e.PropertyName == Shell.TabBarIsVisibleProperty.PropertyName)
        UpdateTabBarHidden();
    else if (e.PropertyName == PlatformConfiguration.iOSSpecific.Page.LargeTitleDisplayProperty.PropertyName)
        UpdateLargeTitles();
}

Impact: MEDIUM - Users might want to toggle this dynamically (though uncommon)

---

2. Performance Consideration - ViewWillLayoutSubviews

Observation: UpdateLargeTitles() is called in ViewWillLayoutSubviews(), which executes on every layout pass (very frequently).

Analysis:

• Setting navigation bar properties repeatedly could be inefficient
• However, UpdateTabBarHidden() already uses this pattern
• iOS likely optimizes no-op property sets

Potential optimization (optional):

LargeTitleDisplayMode? _lastLargeTitleDisplayMode;

void UpdateLargeTitles()
{
    var page = _displayedPage;
    if (page is null || !OperatingSystem.IsIOSVersionAtLeast(11))
        return;

    var largeTitleDisplayMode = page.OnThisPlatform().LargeTitleDisplay();
    
    // Only update if changed
    if (_lastLargeTitleDisplayMode == largeTitleDisplayMode)
        return;
        
    _lastLargeTitleDisplayMode = largeTitleDisplayMode;
    
    // ... rest of implementation
}

Impact: LOW - Likely not a real performance issue, iOS handles repeated property sets efficiently

---

3. Test Coverage Gaps

Current test:

• Only tests LargeTitleDisplay="Always"
• Uses screenshot verification (good)
• Simple single-page Shell

Missing scenarios:

1. LargeTitleDisplay="Never" - should show regular title
2. LargeTitleDisplay="Automatic" - should follow system behavior
3. Multi-page navigation - title mode changes when navigating
4. Dynamic property changes - changing mode at runtime
5. Shell with multiple tabs - each tab can have different modes

Suggested additional tests (future enhancement):

[Test]
public void LargeTitleDisplayNever()
{
    // Verify standard title bar height
}

[Test]
public void LargeTitleDisplayAutomatic()
{
    // Verify automatic behavior (large on first page, small after scroll/navigation)
}

Impact: MEDIUM - Current test validates basic functionality, but edge cases untested

---

🛑 Testing Status - CHECKPOINT REQUIRED

Environment Limitation

Issue: PR review is being performed in a Linux environment without iOS simulators.
Required: iOS simulator or physical device to validate:

1. Large title actually displays correctly
2. Title size changes between Always/Never/Automatic modes
3. Navigation between pages preserves settings
4. No visual glitches or layout issues

Checkpoint for iOS Testing

Platform: iOS 17+ (iPhone Xs or later recommended)
Why needed: Visual validation of large title behavior requires running on iOS

Testing steps needed:

1. Build Sandbox app with test scenario:

   # Modify src/Controls/samples/Controls.Sample.Sandbox/MainPage.xaml to:
   # - Create a Shell with LargeTitleDisplay="Always"
   # - Add navigation button to test with LargeTitleDisplay="Never"
   # - Add another button for "Automatic" mode
   
   # Build for iOS
   dotnet build src/Controls/samples/Controls.Sample.Sandbox/Maui.Controls.Sample.Sandbox.csproj -f net10.0-ios
   
   # Install to simulator
   xcrun simctl install $UDID artifacts/bin/Maui.Controls.Sample.Sandbox/Debug/net10.0-ios/iossimulator-arm64/Maui.Controls.Sample.Sandbox.app
   
   # Launch and capture screenshots
   xcrun simctl launch --console-pty $UDID com.microsoft.maui.sandbox

2. Visual verification:

   • Screenshot with LargeTitleDisplay="Always" - title should be LARGE
   • Screenshot with LargeTitleDisplay="Never" - title should be regular size
   • Screenshot with LargeTitleDisplay="Automatic" - title should be large initially
   • Navigate to second page - verify title behavior changes as expected

3. Edge case testing:

   • Change property dynamically at runtime (if implemented)
   • Navigate back and forth between pages
   • Switch between Shell tabs (if multi-tab)

Resume instructions: After iOS testing is complete, update this review document with:

• Test results (pass/fail for each scenario)
• Screenshots showing large title vs regular title
• Any visual issues discovered

---

Current Recommendation

✅ Approve with Optional Improvements

Optional Cleanup (Non-Blocking)

1. 🟡 Remove redundant condition in UI test (Line 1 of Issue12156.cs)
   • Current: #if TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_WINDOWS
   • Cleaner: #if TEST_FAILS_ON_ANDROID && TEST_FAILS_ON_WINDOWS
   • Impact: Cosmetic only - code works correctly either way

Recommended Improvements (Non-Blocking)

1. 🟡 Add property change listener for dynamic LargeTitleDisplay updates (see suggestion above)
2. 🟡 Expand test coverage to include Never/Automatic modes (future enhancement)
3. 🟡 Consider caching last display mode to avoid redundant property sets (optional performance optimization)

---

Post-iOS-Testing Update

iOS testing status: Unable to complete due to Linux environment limitation (no iOS simulators available)

Recommendation without iOS testing: Based on code review alone, the implementation appears correct:

• Proper use of iOS APIs
• Correct lifecycle integration
• Appropriate null safety and version checks
• Follows established patterns in the codebase

Ideal validation (when iOS environment is available):

1. Visual confirmation that large titles display correctly
2. Verification of Always/Never/Automatic modes
3. Test navigation between pages with different settings
4. Confirm no visual glitches or layout issues

Current recommendation: ✅ Approve - Code quality is excellent, iOS testing would provide additional confidence but is not blocking

---

Related Documentation

• iOS Large Title Documentation
• UINavigationBar.prefersLargeTitles
• .NET MAUI Platform Specifics - iOS

---

Review History

• 2025-11-20: Initial code review complete, iOS testing checkpoint created
• Pending: iOS simulator validation

[jfversluis]

@kubaflo I think this needs snapshot update?

[kubaflo]

@kubaflo I think this needs snapshot update?

Fixed

[jfversluis]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jfversluis]

/azp run MAUI-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).