[Android] Fix custom WebViewClient being overridden by MAUI handler mapper

[NirmalKumarYuvaraj]

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!

Root Cause

The MAUI handler lifecycle calls ConnectHandler before the property mappers run. When a developer sets a custom WebViewClient in ConnectHandler, the subsequent execution of MapWebViewClient (triggered by the mapper pipeline) would call platformView.SetWebViewClient(new MauiWebViewClient(...)), silently discarding the custom client. Since MapWebViewClient and MapWebChromeClient serve no purpose beyond initial setup — they are not responding to any virtual view property change — registering them in the mapper was incorrect. Moving client creation to CreatePlatformView() and removing them from the mapper pipeline ensures the default clients are set once, before ConnectHandler runs, allowing developers to override them reliably.

Description of Change

On Android, WebViewHandler registered MapWebViewClient and MapWebChromeClient as property mapper entries. These mappers created new MauiWebViewClient/MauiWebChromeClient instances and set them on the platform view every time they ran — after ConnectHandler was called. This meant any custom WebViewClient set by users in ConnectHandler (e.g., to intercept navigation via ShouldOverrideUrlLoading) would be silently replaced by MAUI's default client.

Changes:

• Removed MapWebViewClient and MapWebChromeClient mapper methods entirely
• Default clients are now created once in CreatePlatformView() and stored as private fields (_webViewClient, _webChromeClient)
• DisconnectHandler uses the stored field references directly for Disconnect() and Dispose(), rather than casting from the platform view
• Users can now safely override the WebViewClient in ConnectHandler without MAUI replacing it

Issues Fixed

Fixes #34392

[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 -- 34426

Or

• Run remotely in PowerShell:

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

[NirmalKumarYuvaraj]

@kubaflo , Addressed Test case failures. Please let me know if you have any concerns.

[Copilot]

Pull request overview

Fixes an Android handler lifecycle issue in .NET MAUI where WebViewHandler’s property mapper would overwrite a custom WebViewClient set by apps in ConnectHandler, preventing reliable ShouldOverrideUrlLoading interception.

Changes:

• Remove MapWebViewClient / MapWebChromeClient from the Android property mapper and initialize default clients once during platform view creation.
• Update Android DisconnectHandler to disconnect/dispose stored client instances instead of casting from the platform view.
• Add a new HostApp repro page + UITest coverage for issue #34392 to validate custom WebViewClient behavior.

Reviewed changes

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

Show a summary per file

File	Description
src/Core/src/PublicAPI/net-android/PublicAPI.Unshipped.txt	Records removal of Android WebViewHandler mapper APIs (but currently conflicts with shipped API state).
src/Core/src/Handlers/WebView/WebViewHandler.cs	Removes Android mapper entries that were reassigning clients after ConnectHandler.
src/Core/src/Handlers/WebView/WebViewHandler.Android.cs	Creates default MauiWebViewClient/MauiWebChromeClient in CreatePlatformView() and adjusts disconnect/disposal behavior.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue34392.cs	Adds an Android-only UITest to validate ShouldOverrideUrlLoading gets called.
src/Controls/tests/TestCases.HostApp/MauiProgram.cs	Registers the custom handler used for the repro/test.
src/Controls/tests/TestCases.HostApp/Issues/Issue34392.cs	Adds the HostApp issue page + custom WebView/handler/client used by the test.

Comments suppressed due to low confidence (1)

src/Core/src/Handlers/WebView/WebViewHandler.Android.cs:97

• The PR removes MapWebViewClient/MapWebChromeClient methods, but these APIs are already listed in src/Core/src/PublicAPI/net-android/PublicAPI.Shipped.txt. Removing shipped public APIs is a breaking change and will also cause PublicAPI analyzer failures unless handled as a shipped removal. Prefer keeping these methods (even if they’re no longer used by the mapper) and/or marking them obsolete, rather than deleting them outright.

		public static void MapSource(IWebViewHandler handler, IWebView webView)
		{
			ProcessSourceWhenReady(handler, webView);
		}

		public static void MapUserAgent(IWebViewHandler handler, IWebView webView)
		{
			handler.PlatformView.UpdateUserAgent(webView);
		}

		public static void MapWebViewSettings(IWebViewHandler handler, IWebView webView)
		{
			handler.PlatformView.UpdateSettings(webView, true, true);
		}

[kubaflo]

Could you please check copilot's suggestions and the ai's summary?

[NirmalKumarYuvaraj]

@kubaflo , Addressed AI summary.

[kubaflo]

Could you please resolve conflicts?

[NirmalKumarYuvaraj]

@kubaflo , Rebased and resolved the conflicts. Please let me know if you have any concern.

[github-actions]

Tests Failure Analysis

@NirmalKumarYuvaraj — test-failure review results are available based on commit 3706925.
To request a fresh review after new comments, commits, or CI runs, comment /review tests.

Test Failure Review: Insufficient data - click to expand

Overall verdict: Insufficient data — all three PR pipeline builds (maui-pr, maui-pr-devicetests, maui-pr-uitests) returned HTTP 404 and could not be inspected, so zero distinct failures were extracted and merge readiness cannot be judged. No base-branch builds (net11.0) were available to compare against (0 base builds sampled), so nothing can be attributed as regressed vs base or dismissed as pre-existing.

• i Uncertain — Inaccessible AzDO builds (~11 legs): every failing leg across maui-pr, maui-pr-devicetests, and maui-pr-uitests sits on builds that returned 404, so no logs or test results were readable (e.g. iOS UITests CoreCLR Controls (vlatest) CollectionView).
• i Uncertain — Device-test / aborted checks (~6 legs): 4 device-test checks could not be positively confirmed green (Failed == 0 unverified) and 2 failing checks did not finish cleanly (cancelled), none of which can be masked green.

Coverage: 138 checks · 126 passing · 12 failing · 0 pending · 11 inaccessible · 1 unmapped · 0 unexplained build legs · 0 unaccounted failing checks · 2 aborted failing checks · 0 canceled-build checks · 4 device-test unverified · 0 unattributed · 0 regressed-vs-base. Deterministic ceiling: Insufficient data — 11 failing check(s) could not be inspected (AzDO build/logs inaccessible).

Builds (this PR): maui-pr 1494709 · maui-pr-devicetests 1494711 · maui-pr-uitests 1494710. Base sampling (net11.0, 0 recent builds): none available.

Recommended action

A human should re-check the AzDO builds once they are accessible (the 404s suggest transient/permission issues); re-run /review tests after CI is reachable to obtain a real merge-readiness verdict.

[kubaflo]

Could you please check the suggestions?

[MauiBot]

AI Review Summary

ℹ️ The review agent did not produce a full summary on this run (an infrastructure issue on the CI agent), but the deep UI tests completed — their results are below. Re-comment /review for a fresh full review.

⚠️ Deep UI tests — 167 passed; the HostApp crashed mid-run, so 1 test could not complete. An app crash can be an infrastructure flake OR a regression introduced by this PR — review the screenshots + logcat in the drop-deep-uitests artifact before concluding.

🧪 UI Test Execution Results (deep, platform pool)

Category	Tests	Snapshot diffs
ViewBaseTests	118/119 ✓	—
WebView	49/50 (app crashed; 1 couldn't complete)	—

⚠️ WebView — app crashed mid-run; 1 test could not complete

The HostApp crashed during this category (a test failed in TearDown with investigate as possible crash); every following OneTimeSetUp then timed out waiting for the test gallery to reappear. This can be an emulator/infrastructure flake OR a regression introduced by this PR — review the screenshots and logcat in the ui-diagnostics folder of the artifact before concluding.

The app was expected to be running still, investigate as possible crash
TearDown : The app was expected to be running still, investigate as possible crash
at UITest.Appium.NUnit.UITestBase.UITestBaseTearDown() in /_/src/TestUtils/src/UITest.NUnit/UITestBase.cs:line 159
   at UITest.Appium.NUnit.UITestBase.TestTearDown() in /_/src/TestUtils/src/UITest.NUnit/UITestBase.cs:line 45

--TearDown
   at UITest.Appium.NUnit.UITestBase.UITestBaseTearDown() in /_/src/TestUtils/src/UITest.NUnit/UITestBase.cs:line 159
   at UITest.Appium.NUnit.UITestBase.TestTearDown() in /_/src/TestUtils/src/UITest.NUnit/UITestBase.cs:line 45

1)    at UITest.Appium.NUnit.UITestBase.UITestBaseTearDown() in /_/src/TestUtils/src/UITest.NUnit/UITestBase.cs:line 159
   at UITest.Appium.NUnit.UITestBase.TestTearDown() in /_/src/TestUtils/src/UITest.NUnit/UITestBase.cs:line 45

📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)