[Android] Fix BlazorWebView back callback can swallow the first Back press when its callback is stale-enabled

[devanathan-vaithiyanathan]

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 whether this change resolves your issue. Thank you!

Issue Details

BlazorWebView back handling where a stale-enabled OnBackPressedCallback can consume the first Back press even when the WebView cannot go back. This happened after the move to OnBackPressedDispatcher callbacks, because the fallback path disabled the callback but did not forward the same Back event, so users had to press Back twice.

Description of Change

The change fixes that by keeping the same callback model but updating fallback behavior. In BlazorWebViewHandler.Android.cs, the callback now has a dispatcher reference, and when it cannot handle back it sets Enabled = false and immediately calls OnBackPressedDispatcher.OnBackPressed(). That forwards the current Back press to the next handler/system right away instead of swallowing it. The callback still gets re-enabled through UpdateBackNavigationState() when navigation history changes, so predictive-back behavior remains correct.

Issues Fixed

Fixes #35573

Tested the behavior in the following platforms.

• Android
• Windows
• iOS
• Mac

Before	After
Android Before.mov	Android After.mov

[kubaflo]

/review -b feature/refactor-copilot-yml

[MauiBot]

🤖 AI Summary

👋 @devanathan-vaithiyanathan — new AI review results are available. Please review the latest session below.

📊 Review Session — 360751c · fix added · 2026-05-26 10:45 UTC

🚦 Gate — Test Before & After Fix

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent.

---

🧪 UI Tests

No UI test categories needed for this PR (no UI-relevant changes).

---

🔍 Regression Cross-Reference

🔍 Regression Cross-Reference

🟢 No regression risks detected. No labeled bug-fix PRs in the last 6 months touched the modified files.

---

🔍 Pre-Flight — Context & Validation

Issue: #35573 - [inflight regression] Android BlazorWebView back callback can swallow the first Back press when its callback is stale-enabled
PR: #35611 - [Android] Fix BlazorWebView back callback can swallow the first Back press when its callback is stale-enabled
Platforms Affected: Android
Files Changed: 1 implementation, 1 test

Key Findings

• Issue [inflight regression] Android BlazorWebView back callback can swallow the first Back press when its callback is stale-enabled #35573 is an Android regression introduced by PR [Android] Fix for BlazorWebView predictive back callback blocks Android back-to-home animation  #35538 where BlazorWebViewHandler uses OnBackPressedCallback; when the callback is stale-enabled but WebView.CanGoBack() is false, the callback disables itself but the current Back event is swallowed.
• PR [Android] Fix BlazorWebView back callback can swallow the first Back press when its callback is stale-enabled #35611 fixes the fallback by storing OnBackPressedDispatcher in the callback and calling OnBackPressed() again after setting Enabled = false, so the same Back press reaches the next lower-priority callback/system handler.
• The PR also adds an Android BlazorWebView device test that forces the callback into a stale-enabled state and verifies the lower-priority callback receives both first and second Back presses.
• Gate result provided by caller: skipped because no tests were detected by the separate gate step; no gate rerun was performed.

Code Review Summary

Verdict: NEEDS_DISCUSSION
Confidence: medium
Errors: 0 | Warnings: 1 | Suggestions: 0

Key code review findings:

• ⚠️ No code-level errors or inline findings were found (inline-findings.json was []), but the code-review subagent reported NEEDS_DISCUSSION because required CI was failing/unstable and should not be treated as LGTM until CI is green or failures are waived as unrelated.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #35611	Keep the callback registered; on fallback set Enabled = false and redispatch via OnBackPressedDispatcher.OnBackPressed() so the same Back press reaches the next handler.	⚠️ Gate skipped	src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs, src/BlazorWebView/tests/DeviceTests/Elements/BlazorWebViewTests.BackNavigation.cs	Original PR

---

🔬 Code Review — Deep Analysis

Code Review — PR #35611

Independent Assessment

What this changes: Android BlazorWebView back handling now passes the activity OnBackPressedDispatcher into the registered callback. If the callback is stale-enabled but the WebView is detached, unfocused, or cannot go back, it disables itself and redispatches the same back press so the next callback/system handler receives it immediately.
Inferred motivation: Prevent a stale BlazorWebView back callback from swallowing the first Back press and requiring a second press.

Reconciliation with PR Narrative

Author claims: The PR fixes issue #35573 by forwarding the current Back event when the BlazorWebView callback cannot handle it, while preserving UpdateBackNavigationState() re-enablement behavior.
Agreement/disagreement: This matches the code in BlazorWebViewHandler.Android.cs:103 and :275-279, and the added device test forces the stale-enabled state and verifies the lower-priority callback receives both presses. No existing review comments to duplicate.

Findings

⚠️ Warning — Required CI is currently failing

PR checks show maui-pr failing. The visible failures appear unrelated to this Android BlazorWebView change: Windows Debug build hit a locked .buildtasks\Microsoft.Maui.Core.BundledVersions.targets, macOS RunOniOS NativeAOT failed provisioning JDK due Homebrew/ruby download HTTP 502, and Windows Helix UnitTests failed in unrelated dispatcher/unit-test cases. Still, per review rules this is not merge-ready until CI is green or explicitly waived.

Devil's Advocate

The redispatch call is intentionally after Enabled = false, so the dispatcher should skip this callback and avoid recursion. Holding the dispatcher reference does not introduce a handler leak because the callback is removed/disposed in DisconnectHandler, and it already holds only a weak WebView reference. I did not run Android device tests locally, so behavioral confidence relies on code analysis, the added device test, and CI status.

Verdict: NEEDS_DISCUSSION

Confidence: medium
Summary: I found no code-level errors or inline findings; the approach is narrow and matches the reported regression. However, required CI is red, so this should not be treated as LGTM until the failures are resolved, rerun, or accepted as unrelated infrastructure/pre-existing issues.

---

🔧 Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix-1 / claude-opus-4.6	Dynamically resolve Platform.CurrentActivity at fallback time, disable callback, then redispatch via the current activity dispatcher instead of storing OnBackPressedDispatcher in the callback.	⚠️ BLOCKED	3 files	Built/deployed, but Android BlazorWebView suite hit WebView initialization timeouts. Functionally close to PR fix, but with dynamic dispatcher lookup.
2	try-fix-2 / expert loop	Prevent stale enablement by enabling the callback only when the WebView is attached, focused, and can go back; no redispatch.	⚠️ BLOCKED / logically insufficient	1 file	Would still fail when callback is already stale-enabled because fallback disables and returns, consuming the current event.
3	try-fix-3 / expert loop	On stale fallback, disable and remove the callback from the dispatcher instead of redispatching.	⚠️ BLOCKED / logically insufficient	1 file	AndroidX dispatcher does not resume the same dispatch after the selected callback removes itself; current event remains consumed.
PR	PR #35611	Store OnBackPressedDispatcher; on fallback set Enabled = false then call OnBackPressed() so the same event reaches the next callback/system handler.	⚠️ Gate skipped	2 files	Original PR. Best candidate because it handles the already-stale-enabled case directly and matches the regression test.

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	1	Yes	Dynamic activity lookup for redispatch. Blocked by environment; not demonstrably better than PR because it is equivalent redispatch with a different dispatcher source.
expert-review loop	1	Yes	Prevent stale enablement through stricter Enabled state. Rejected after failure analysis because it does not fix already-stale callbacks.
expert-review loop	1	Yes	Remove callback on fallback. Rejected after dispatcher semantics review because removal does not forward the same Back press.
expert-review loop	2	No	Remaining meaningful alternatives collapse into either redispatching the same event (the PR's core approach) or returning false from a different API layer, which would undo the AndroidX callback/predictive-back design from the preceding regression fix.

Exhausted: Yes
Selected Fix: PR #35611 — It is the only explored approach that directly handles an already stale-enabled AndroidX callback and forwards the current Back event. Candidate 1 is not demonstrably better; candidates 2 and 3 do not satisfy the repro semantics.

---

Attempt 1 Narrative

Try-Fix Attempt 1: Dynamic Activity Lookup for Redispatch

Approach

Instead of storing the OnBackPressedDispatcher as a field in the callback (PR #35611 approach),
dynamically resolve the current ComponentActivity at back-press time via
Microsoft.Maui.ApplicationModel.Platform.CurrentActivity. When the callback is stale-enabled
and cannot handle the back press, disable self and call
currentActivity.OnBackPressedDispatcher.OnBackPressed() using the dynamically-resolved activity.

Key difference from PR fix: No dispatcher stored in the callback class. The callback only
holds a WeakReference. At invocation time, it resolves the activity via
Platform.CurrentActivity, making it resilient to activity recreation (configuration changes).

Files Changed

• src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs — Replaced lifecycle
  event + PredictiveBackCallback with AndroidX OnBackPressedCallback using dynamic dispatcher
• src/BlazorWebView/src/Maui/Android/BlazorAndroidWebView.cs — Removed unused
  BackNavigationHandled property and OnKeyDown override
• src/BlazorWebView/src/Maui/Android/WebKitWebViewClient.cs — Added
  UpdateBackNavigationState calls in OnPageFinished and DoUpdateVisitedHistory

Diff

diff --git a/src/BlazorWebView/src/Maui/Android/BlazorAndroidWebView.cs b/src/BlazorWebView/src/Maui/Android/BlazorAndroidWebView.cs
index fb98ef7ed2..972013d7ad 100644
--- a/src/BlazorWebView/src/Maui/Android/BlazorAndroidWebView.cs
+++ b/src/BlazorWebView/src/Maui/Android/BlazorAndroidWebView.cs
@@ -1,5 +1,4 @@
 using Android.Content;
-using Android.Views;
 using AWebView = Android.Webkit.WebView;
 
 namespace Microsoft.AspNetCore.Components.WebView.Maui
@@ -9,8 +8,6 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 	/// </summary>
 	internal class BlazorAndroidWebView : AWebView
 	{
-		internal bool BackNavigationHandled { get; set; }
-
 		/// <summary>
 		/// Initializes a new instance of <see cref="BlazorAndroidWebView"/>
 		/// </summary>
@@ -18,17 +15,5 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 		public BlazorAndroidWebView(Context context) : base(context)
 		{
 		}
-
-		public override bool OnKeyDown(Keycode keyCode, KeyEvent? e)
-		{
-			if (keyCode == Keycode.Back && CanGoBack() && e?.RepeatCount == 0)
-			{
-				GoBack();
-				BackNavigationHandled = true;
-				return true;
-			}
-			BackNavigationHandled = false;
-			return false;
-		}
 	}
 }
diff --git a/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs b/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
index daab566211..e416cfd489 100644
--- a/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
+++ b/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
@@ -1,8 +1,8 @@
 using System;
 using System.Threading.Tasks;
-using Android.Window;
 using Android.Webkit;
 using Android.Widget;
+using AndroidX.Activity;
 using Microsoft.Extensions.DependencyInjection;
 using Microsoft.Extensions.FileProviders;
 using Microsoft.Extensions.Logging;
@@ -10,7 +10,6 @@ using Microsoft.Extensions.Logging.Abstractions;
 using Microsoft.Maui;
 using Microsoft.Maui.Dispatching;
 using Microsoft.Maui.Handlers;
-using Microsoft.Maui.LifecycleEvents;
 using static global::Android.Views.ViewGroup;
 using AWebView = global::Android.Webkit.WebView;
 using Path = System.IO.Path;
@@ -23,27 +22,11 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 		private WebChromeClient? _webChromeClient;
 		private AndroidWebKitWebViewManager? _webviewManager;
 		internal AndroidWebKitWebViewManager? WebviewManager => _webviewManager;
-		private AndroidLifecycle.OnBackPressed? _onBackPressedHandler;
-		BlazorWebViewPredictiveBackCallback? _predictiveBackCallback;
+		private OnBackPressedCallback? _backPressedCallback;
 
 		private ILogger? _logger;
 		internal ILogger Logger => _logger ??= Services!.GetService<ILogger<BlazorWebViewHandler>>() ?? NullLogger<BlazorWebViewHandler>.Instance;
 
-		/// <summary>
-		/// Gets the concrete LifecycleEventService to access internal RemoveEvent method.
-		/// RemoveEvent is internal because it's not part of the public ILifecycleEventService contract,
-		/// but is needed for proper cleanup of lifecycle event handlers.
-		/// </summary>
-		private LifecycleEventService? TryGetLifecycleEventService()
-		{
-			var services = MauiContext?.Services;
-			if (services != null)
-			{
-				return services.GetService<ILifecycleEventService>() as LifecycleEventService;
-			}
-			return null;
-		}
-
 		protected override AWebView CreatePlatformView()
 		{
 			Logger.CreatingAndroidWebkitWebView();
@@ -80,63 +63,23 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 		}
 
 		/// <summary>
-		/// Connects the handler to the Android <see cref="AWebView"/> and registers platform-specific
-		/// back navigation handling so that the WebView can consume back presses before the page is popped.
+		/// Connects the handler to the Android <see cref="AWebView"/> and registers an
+		/// <see cref="OnBackPressedCallback"/> so the WebView can consume back presses
+		/// before the containing page is popped or the back-to-home animation plays.
 		/// </summary>
 		/// <param name="platformView">The native Android <see cref="AWebView"/> instance associated with this handler.</param>
-		/// <remarks>
-		/// This override calls the base implementation and then registers an <see cref="AndroidLifecycle.OnBackPressed"/>
-		/// lifecycle event handler. The handler checks <see cref="AWebView.CanGoBack"/> and, when possible, navigates
-		/// back within the WebView instead of allowing the back press (or predictive back gesture on Android 13+)
-		/// to propagate and pop the containing page.
-		/// <para>
-		/// When multiple BlazorWebView instances exist, the handler includes focus and visibility checks to ensure
-		/// only the currently visible and focused WebView handles the back navigation, preventing conflicts between instances.
-		/// </para>
-		/// Inheritors that override this method should call the base implementation to preserve this back navigation
-		/// behavior unless they intentionally replace it.
-		/// </remarks>
 		protected override void ConnectHandler(AWebView platformView)
 		{
 			base.ConnectHandler(platformView);
 
-			// Register OnBackPressed lifecycle event handler to check WebView's back navigation
-			// This ensures predictive back gesture (Android 13+) checks WebView.CanGoBack() before popping page
-			var lifecycleService = TryGetLifecycleEventService();
-			if (lifecycleService != null)
+			// Use OnBackPressedCallback (AndroidX) so that when the WebView has no back history
+			// (Enabled = false), the system predictive back-to-home animation plays naturally.
+			// Note: requires ComponentActivity — all MAUI apps satisfy this via MauiAppCompatActivity.
+			if (Microsoft.Maui.ApplicationModel.Platform.CurrentActivity is ComponentActivity activity)
 			{
-				// Create a weak reference to avoid memory leaks
 				var weakPlatformView = new WeakReference<AWebView>(platformView);
-
-				AndroidLifecycle.OnBackPressed handler = (activity) =>
-				{
-					// Check if WebView is still alive, attached to window, and has focus
-					// This prevents non-visible or unfocused BlazorWebView instances from
-					// incorrectly intercepting back navigation when multiple instances exist
-					if (weakPlatformView.TryGetTarget(out var webView) &&
-						webView.IsAttachedToWindow &&
-						webView.HasWindowFocus &&
-						webView.CanGoBack())
-					{
-						webView.GoBack();
-						return true; // Prevent back propagation - handled by WebView
-					}
-
-					return false; // Allow back propagation - let page be popped
-				};
-
-				// Register with lifecycle service - will be invoked by HandleBackNavigation in MauiAppCompatActivity
-				lifecycleService.AddEvent(nameof(AndroidLifecycle.OnBackPressed), handler);
-				_onBackPressedHandler = handler;
-			}
-
-			if (OperatingSystem.IsAndroidVersionAtLeast(33) && _predictiveBackCallback is null)
-			{
-				if (Microsoft.Maui.ApplicationModel.Platform.CurrentActivity is not null)
-				{
-					_predictiveBackCallback = new BlazorWebViewPredictiveBackCallback(this);
-					Microsoft.Maui.ApplicationModel.Platform.CurrentActivity?.OnBackInvokedDispatcher?.RegisterOnBackInvokedCallback(0, _predictiveBackCallback);
-				}
+				_backPressedCallback = new BlazorWebViewBackCallback(weakPlatformView);
+				activity.OnBackPressedDispatcher.AddCallback(activity, _backPressedCallback);
 			}
 		}
 
@@ -144,23 +87,9 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 
 		protected override void DisconnectHandler(AWebView platformView)
 		{
-			if (OperatingSystem.IsAndroidVersionAtLeast(33) && _predictiveBackCallback is not null)
-			{
-				Microsoft.Maui.ApplicationModel.Platform.CurrentActivity?.OnBackInvokedDispatcher?.UnregisterOnBackInvokedCallback(_predictiveBackCallback);
-				_predictiveBackCallback.Dispose();
-				_predictiveBackCallback = null;
-			}
-
-			// Clean up lifecycle event handler to prevent memory leaks
-			if (_onBackPressedHandler != null)
-			{
-				var lifecycleService = TryGetLifecycleEventService();
-				if (lifecycleService != null)
-				{
-					lifecycleService.RemoveEvent(nameof(AndroidLifecycle.OnBackPressed), _onBackPressedHandler);
-					_onBackPressedHandler = null;
-				}
-			}
+			_backPressedCallback?.Remove();
+			_backPressedCallback?.Dispose();
+			_backPressedCallback = null;
 
 			platformView.StopLoading();
 
@@ -281,40 +210,49 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 			return await _webviewManager.TryDispatchAsync(workItem);
 		}
 
-		sealed class BlazorWebViewPredictiveBackCallback : Java.Lang.Object, IOnBackInvokedCallback
+		/// <summary>
+		/// Updates the back navigation callback's enabled state based on the WebView's current
+		/// <see cref="AWebView.CanGoBack"/> status. Call this after any navigation that may
+		/// change the WebView's history.
+		/// </summary>
+		internal void UpdateBackNavigationState()
+		{
+			if (_backPressedCallback is not null && PlatformView is not null)
+			{
+				_backPressedCallback.Enabled = PlatformView.CanGoBack();
+			}
+		}
+
+		sealed class BlazorWebViewBackCallback : OnBackPressedCallback
 		{
-			WeakReference<BlazorWebViewHandler> _weakBlazorWebViewHandler;
+			readonly WeakReference<AWebView> _weakWebView;
 
-			public BlazorWebViewPredictiveBackCallback(BlazorWebViewHandler handler)
+			public BlazorWebViewBackCallback(WeakReference<AWebView> weakWebView) : base(false)
 			{
-				_weakBlazorWebViewHandler = new WeakReference<BlazorWebViewHandler>(handler);
+				_weakWebView = weakWebView;
 			}
 
-			public void OnBackInvoked()
+			public override void HandleOnBackPressed()
 			{
-				// KeyDown for Back button is handled in BlazorAndroidWebView.
-				// Here we just need to check if it was handled there.
-				// If not, we propagate the back press to the Activity's OnBackPressedDispatcher.
-				if (_weakBlazorWebViewHandler is not null && _weakBlazorWebViewHandler.TryGetTarget(out var handler))
+				if (_weakWebView.TryGetTarget(out var webView) &&
+					webView.IsAttachedToWindow &&
+					webView.HasWindowFocus &&
+					webView.CanGoBack())
+				{
+					webView.GoBack();
+					return;
+				}
+
+				// Conditions not met (detached, unfocused, or no history) — disable so the next
+				// callback in the LIFO dispatcher stack can handle this back press.
+				Enabled = false;
+
+				// Dynamically resolve the current activity's dispatcher to redispatch this back
+				// press. Unlike storing the dispatcher as a field, this tolerates activity
+				// recreation (configuration changes) where a cached dispatcher could be stale.
+				if (Microsoft.Maui.ApplicationModel.Platform.CurrentActivity is ComponentActivity currentActivity)
 				{
-					var webView = handler.PlatformView as BlazorAndroidWebView;
-					if (webView is not null)
-					{
-						var wasBackNavigationHandled = webView.BackNavigationHandled;
-						// reset immediately for next back event
-						webView.BackNavigationHandled = false;
-
-						if (!wasBackNavigationHandled)
-						{
-							if (webView.CanGoBack()) // If we can go back in WeView, Navigate back
-							{
-								webView.GoBack();
-								return;
-							}
-							// Otherwise propagate back press to Activity
-							(Microsoft.Maui.ApplicationModel.Platform.CurrentActivity as AndroidX.AppCompat.App.AppCompatActivity)?.OnBackPressedDispatcher?.OnBackPressed();
-						}
-					}
+					currentActivity.OnBackPressedDispatcher.OnBackPressed();
 				}
 			}
 		}
diff --git a/src/BlazorWebView/src/Maui/Android/WebKitWebViewClient.cs b/src/BlazorWebView/src/Maui/Android/WebKitWebViewClient.cs
index debf50d8b5..30012f9776 100644
--- a/src/BlazorWebView/src/Maui/Android/WebKitWebViewClient.cs
+++ b/src/BlazorWebView/src/Maui/Android/WebKitWebViewClient.cs
@@ -149,6 +149,17 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 				// effect because once the page content loads all the document state gets reset.
 				RunBlazorStartupScripts(view);
 			}
+
+			_webViewHandler?.UpdateBackNavigationState();
+		}
+
+		public override void DoUpdateVisitedHistory(AWebView? view, string? url, bool isReload)
+		{
+			base.DoUpdateVisitedHistory(view, url, isReload);
+			// Covers Blazor client-side (SPA) navigations that use pushState/replaceState.
+			// DoUpdateVisitedHistory fires for pushState on all supported Android API levels (24+).
+			// replaceState does not add a new history entry so CanGoBack() is unaffected by it.
+			_webViewHandler?.UpdateBackNavigationState();
 		}
 
 		private void RunBlazorStartupScripts(AWebView view)

Test Results

Result: Blocked

Tests ran on Android emulator (API 30). 23 tests executed:

• 1 passed: BlazorWebViewDispatchBeforeRunningReturnsFalse
• 21 failed: All with identical timeout - "Waited 30000ms but couldnt get window.Blazor to
  be non-null and have window.__BlazorStarted to be true"
• 1 failed: Same timeout for our target test

This is a systemic emulator environment issue — Blazor cannot initialize in the WebView on
this CI agent. The failure affects ALL BlazorWebView tests equally, not just back-navigation tests.

Failure Analysis

The test infrastructure cannot validate the fix because the emulators WebView doesnt
properly start Blazor. This is NOT a code issue — the fix compiled and deployed successfully.
The same failures would occur with the PRs original fix or with no changes at all.

Self-Review

0 findings. The approach passes all relevant MAUI expert reviewer checks:

• Handler lifecycle symmetry (Connect/Disconnect balanced)
• WeakReference prevents memory leaks
• No stored dispatcher = no stale reference risk
• Callback starts disabled (base(false)) — correct initial state
• Dynamic resolution is thread-safe (called on UI thread via OnBackPressedCallback contract)

---

Attempt 2 Narrative

Analysis

Result: Blocked

What happened: Android test execution was not rerun because attempt 1 already demonstrated a suite-wide WebView initialization environment blocker. This candidate was analyzed against the regression test semantics instead.

Why it failed/blocked: The prevention strategy is insufficient for the repro. It reduces ordinary stale-enable windows when UpdateBackNavigationState() runs, but it does not handle a callback that is already enabled when the dispatcher invokes it. The PR's regression test manually forces that state, and real lifecycle races can still produce it between state updates.

Self-review: 0 JSON findings recorded; however, manual expert review identifies a correctness flaw: the fallback still consumes the current Back press.

Insights: A robust fix needs a fallback path that yields the current dispatcher event, not only better enabled-state maintenance.

Approach: Prevent Stale Enablement with Stricter Callback State

Instead of redispatching from the fallback path, make UpdateBackNavigationState() keep the AndroidX back callback enabled only when the WebView is attached, focused, and can go back. If any of those conditions is false, the callback is disabled before the dispatcher can invoke it.

Different from existing fix: PR #35611 repairs stale-enabled fallback by redispatching the same Back event. This candidate tries to prevent stale enablement rather than forwarding after stale invocation.

Diff

diff --git a/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs b/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
index ff348f1352..96490c6bd8 100644
--- a/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
+++ b/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
@@ -100,7 +100,7 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 			if (Microsoft.Maui.ApplicationModel.Platform.CurrentActivity is ComponentActivity activity)
 			{
 				var weakPlatformView = new WeakReference<AWebView>(platformView);
-				_backPressedCallback = new BlazorWebViewBackCallback(weakPlatformView, activity.OnBackPressedDispatcher);
+				_backPressedCallback = new BlazorWebViewBackCallback(weakPlatformView);
 				activity.OnBackPressedDispatcher.AddCallback(activity, _backPressedCallback);
 			}
 		}
@@ -241,19 +241,20 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 		{
 			if (_backPressedCallback is not null && PlatformView is not null)
 			{
-				_backPressedCallback.Enabled = PlatformView.CanGoBack();
+				_backPressedCallback.Enabled =
+					PlatformView.IsAttachedToWindow &&
+					PlatformView.HasWindowFocus &&
+					PlatformView.CanGoBack();
 			}
 		}
 
 		sealed class BlazorWebViewBackCallback : OnBackPressedCallback
 		{
 			readonly WeakReference<AWebView> _weakWebView;
-			readonly OnBackPressedDispatcher _dispatcher;
 
-			public BlazorWebViewBackCallback(WeakReference<AWebView> weakWebView, OnBackPressedDispatcher dispatcher) : base(false)
+			public BlazorWebViewBackCallback(WeakReference<AWebView> weakWebView) : base(false)
 			{
 				_weakWebView = weakWebView;
-				_dispatcher = dispatcher;
 			}
 
 			public override void HandleOnBackPressed()
@@ -267,16 +268,7 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 					return;
 				}
 
-				// Conditions not met (detached, unfocused, or no history) — disable so the next
-				// callback in the LIFO dispatcher stack can handle this back press. This is important
-				// for multiple BlazorWebView instances: the last-added callback fires first; if it
-				// can't handle the press it must yield rather than silently consuming the event.
-				// UpdateBackNavigationState() will re-enable this callback on the next navigation.
 				Enabled = false;
-
-				// Redispatch this same back press so it is not swallowed when this callback was
-				// stale-enabled and no longer able to handle.
-				_dispatcher.OnBackPressed();
 			}
 		}
 	}

Test Results

Test phase skipped after attempt 1 established an Android environment blocker: BlazorWebView device tests build/deploy, but WebView initialization times out across the suite (window.Blazor never becomes non-null / __BlazorStarted never becomes true). Per autonomous-execution instructions, blocked test phases are recorded and the loop continues.

Logical regression check against PR test: this candidate would not satisfy BackCallbackConsumesFirstBackPressWhenStaleEnabledRepro because the test explicitly forces blazorBackCallback.Enabled = true; if the callback is invoked while unable to handle, it still disables itself and returns without forwarding the same Back press.

---

Attempt 3 Narrative

Analysis

Result: Blocked

What happened: The Android test phase was skipped due the previously observed BlazorWebView initialization blocker. Expert review was applied to dispatcher semantics.

Why it failed/blocked: The approach is not viable. OnBackPressedDispatcher does not re-run dispatch just because the selected callback removes itself during HandleOnBackPressed(). The selected callback has already consumed the event, so the lower-priority callback/system handler still requires a second Back press.

Self-review: 0 JSON findings recorded for file format, but manual expert review rejects the approach as a logic/correctness failure.

Insights: Mutating callback registration during the callback is not equivalent to forwarding the current event. The fallback must explicitly redispatch or use an API that can return false for the same event.

Approach: Self-Remove Stale Callback

When the AndroidX callback is invoked but the WebView cannot handle Back, disable and remove the callback from the dispatcher instead of redispatching through OnBackPressedDispatcher.

Different from existing fix: PR #35611 keeps the callback registered and explicitly forwards the same Back press. This candidate tries to make the dispatcher continue naturally by removing the stale callback from the callback stack.

Diff

diff --git a/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs b/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
index ff348f1352..ce96d590d3 100644
--- a/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
+++ b/src/BlazorWebView/src/Maui/Android/BlazorWebViewHandler.Android.cs
@@ -273,10 +273,7 @@ namespace Microsoft.AspNetCore.Components.WebView.Maui
 				// can't handle the press it must yield rather than silently consuming the event.
 				// UpdateBackNavigationState() will re-enable this callback on the next navigation.
 				Enabled = false;
-
-				// Redispatch this same back press so it is not swallowed when this callback was
-				// stale-enabled and no longer able to handle.
-				_dispatcher.OnBackPressed();
+				Remove();
 			}
 		}
 	}

Test Results

Test phase skipped after attempt 1 established an Android environment blocker: BlazorWebView device tests build/deploy, but WebView initialization times out across the suite. Per autonomous-execution instructions, blocked test phases are recorded and the loop continues.

Logical regression check: AndroidX OnBackPressedDispatcher invokes the first enabled callback and returns. Removing the callback inside HandleOnBackPressed does not cause the dispatcher to resume iteration for the same Back event, so the current Back press remains consumed.

---

📋 Report — Final Recommendation

Comparative Fix Report — PR #35611

Candidates compared

Candidate	Approach	Regression-test status	Assessment	Rank
pr	Store the registering OnBackPressedDispatcher; on stale fallback set Enabled = false, then redispatch the same Back event so the next callback/system handler receives the current press.	Gate skipped; added device test targets repro	Best direct fix. It handles an already stale-enabled callback, avoids recursion by disabling before redispatch, and expert review found no actionable code issues.	1
pr-plus-reviewer	Same as pr; expert reviewer produced no actionable feedback to apply.	Same as pr	Equivalent to pr, but not ranked above it because it contains no improvement over the submitted fix.	2
try-fix-1	Dynamically resolve Platform.CurrentActivity at fallback time, disable callback, then redispatch through the current activity dispatcher.	Blocked by Android WebView initialization timeouts	Functionally close to the PR and potentially resilient to activity recreation, but not demonstrably better. Dynamic current-activity lookup also risks redispatching through a different activity if lifecycle state changes, while the PR uses the dispatcher that owns the callback.	3
try-fix-2	Prevent stale enablement by enabling only when attached, focused, and able to go back; no redispatch.	Blocked; logically insufficient	Fails the core repro semantics. If the callback is already stale-enabled when selected by the dispatcher, disabling and returning still consumes the current Back press.	4
try-fix-3	Disable and remove the stale callback during HandleOnBackPressed() instead of redispatching.	Blocked; logically insufficient	Also fails the core repro semantics. AndroidX OnBackPressedDispatcher does not continue dispatching the same event just because the selected callback removes itself.	5

Winning candidate

Winner: pr

The submitted PR fix is the only passing/viable candidate that directly addresses an already stale-enabled AndroidX callback and forwards the same Back press. pr-plus-reviewer is equivalent because expert review found no actionable changes, and all try-fix-* candidates are ranked lower because they were blocked or logically fail the repro semantics.

Test consideration

The supplied gate result was skipped because no tests were detected. The PR does include an Android device test for the stale-enabled callback behavior, but merge confidence would be higher if that test is detected and run by the normal validation path.

---