[Android] Fix BlazorWebView back callback can swallow the first Back press when its callback is stale-enabled#35611
Conversation
dotnet-policy-service
Bot
added
the
partner/syncfusion
github-actions
Bot
added
area-blazor
|
/review -b feature/refactor-copilot-yml |
MauiBot
added
s/agent-fix-pr-picked
🤖 AI Summary
📊 Review Session —
|
| # | 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. |
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. |
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. | 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. | 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. |
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.
…press when its callback is stale-enabled (#35611) <!-- Please keep the note below for people who 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 whether this change resolves your issue. Thank you!<!-- !!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING MAIN. !!!!!!! --> ### 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 <!-- Enter description of the fix in this section --> 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 <!-- 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 #35573 <!-- Are you targeting main? All PRs should target the main branch unless otherwise noted. --> **Tested the behavior in the following platforms.** - [x] Android - [ ] Windows - [ ] iOS - [ ] Mac | Before | After | |---------|--------| | **Android**<br> <video src="https://github.com/user-attachments/assets/cfaf9bab-c2a9-4078-a888-1809e33ec53b" width="300" height="600"> | **Android**<br> <video src="https://github.com/user-attachments/assets/2de09a3c-aab5-4163-a7b3-46ce212f4993" width="300" height="600"> |
4 participants
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.
Before.mov
After.mov