[Android] Fix OnBackButtonPressed on root pages

[jfversluis]

Note

@kamano1, thank you for reporting this regression. When the PR artifacts are available, please try them with your application and let us know whether they restore the expected behavior on your affected devices.

Description

Fixes #37706
Fixes #37657
Fixes #38030

.NET MAUI 10.0.100 moved Android back handling entirely to OnBackPressedDispatcher. To preserve Android's predictive back-to-home animation, MAUI enables its callback only when the current page can consume back navigation. A root ContentPage was always classified as unable to consume back, even when application code overrode Page.OnBackButtonPressed(), so Android bypassed MAUI and exited the app.

This change detects the effective virtual OnBackButtonPressed() implementation without invoking user code. Overrides declared by applications or third-party controls now enable MAUI's callback, while ordinary pages and MAUI's framework container implementations retain the existing predictive back-to-home behavior. The result is cached per page and uses a typed delegate, avoiding string-based reflection and linker/AOT concerns.

Tests

• Added unit coverage for plain derived pages, custom ContentPage overrides, and custom NavigationPage overrides.
• Added an Android Appium regression test that installs the issue page as Window.Page, presses the device back button, verifies the override runs exactly once, and verifies the root page remains visible.

Runtime verification

Verified on an Android 16 / API 36 emulator (sdk_gphone64_arm64) using a real Android back key event.

Without the fix, the root page reports that the override has not run, then the app exits to the Android launcher:

Before back	After back

With the fix, the same root page remains foregrounded and reports exactly one invocation:

Before back	After back

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

Or

• Run remotely in PowerShell:

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

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Fixes an Android regression where root ContentPage instances that override Page.OnBackButtonPressed() were incorrectly treated as unable to consume back navigation, causing the OS back handling to bypass MAUI and exit the app (breaking expected override behavior while trying to preserve predictive back).

Changes:

• Add Page.HasBackButtonPressedOverride to detect effective overrides without invoking user code and cache the result per page.
• Update Window.CanConsumeBackNavigation(Page?) to treat pages with app/third-party back overrides as able to consume back (enabling MAUI’s back callback), while leaving framework container behavior unchanged.
• Add unit tests for back-consumption detection and an Android Appium regression test for the root-page override scenario.

Show a summary per file

File	Description
src/Controls/src/Core/Page/Page.cs	Adds cached override-detection for OnBackButtonPressed() based on the effective declaring type/assembly.
src/Controls/src/Core/Window/Window.cs	Uses HasBackButtonPressedOverride to decide whether back can be consumed (predictive back callback enablement).
src/Controls/tests/Core.UnitTests/WindowsTests.cs	Adds unit coverage for derived pages and override scenarios affecting CanConsumeBackNavigation.
src/Controls/tests/TestCases.HostApp/Issues/Issue37706.cs	Adds a HostApp issue page that overrides OnBackButtonPressed() and reports invocation count.
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue37706.cs	Adds Android Appium test validating the override is invoked and the root page remains visible.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

src/Controls/tests/TestCases.HostApp/Issues/Issue37706.cs:6

• This issue page is missing the Maui.Controls.Sample.Issues namespace declaration. The HostApp issue pages are discovered/organized under that namespace (most files in this folder use a file-scoped namespace), so leaving this type in the global namespace risks the page not being found by the issue gallery/test navigation.

[Issue(
	IssueTracker.Github,
	37706,
	"Page.OnBackButtonPressed is not invoked on a root page",
	PlatformAffected.Android)]
public class Issue37706 : ContentPage

src/Controls/tests/TestCases.HostApp/Issues/Issue37706.cs:36

• The status text uses singular "time" for all counts (e.g., "2 time"), which is grammatically incorrect and can make debugging failures harder. Pluralize the suffix so the label reads correctly for any count.

		_statusLabel.Text = $"OnBackButtonPressed called {_backPressCount} time";

• Files reviewed: 5/5 changed files
• Comments generated: 0 new
• Review effort level: Lite

[MauiBot]

Expert Review — 4 findings

See inline comments for details.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[major] Logic and Correctness — The new early-return only inspects the page passed in, and the recursion below never reaches FlyoutPage.Flyout, so a FlyoutPage whose flyout page carries the override is still reported as non-consuming.

FlyoutPage.OnBackButtonPressed (FlyoutPage.cs:239) dispatches to Flyout.SendBackButtonPressed() first when IsPresented, and only then to Detail. But the case FlyoutPage arm below (line ~858) returns true only when IsPresented && CanChangeIsPresented, otherwise recurses into flyoutPage.Detail only — flyoutPage.Flyout is never passed through CanConsumeBackNavigation.

Concrete failing scenario: split-mode FlyoutPage on a tablet/landscape (CanChangeIsPresented == false, IsPresented == true), app-defined flyout page overrides OnBackButtonPressed and returns true, plain ContentPage detail with no override. → first branch is false, CanConsumeBackNavigation(Detail) is false → MauiOnBackPressedCallback.Enabled stays false → the system plays back-to-home and the flyout's override is never invoked. This is the same defect this PR fixes for root pages, unaddressed for the flyout branch, and it contradicts the comment added here ("App and third-party overrides must always receive the back press").

Suggested fix: add || CanConsumeBackNavigation(flyoutPage.Flyout) (guarded by IsPresented, to mirror the dispatch order in FlyoutPage.OnBackButtonPressed) to the FlyoutPage arm, plus a unit test.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[moderate] Trimming/AOT + Performance — new Func<bool>(OnBackButtonPressed).Method allocates a delegate and performs a runtime function-pointer→MethodInfo reverse lookup to derive a fact that is purely type-level, yet it is cached per Page instance (_hasBackButtonPressedOverride). Every Page in the app pays a delegate allocation + Delegate.GetMethodImpl on the first predictive-back state refresh, and every Page instance permanently grows by the extra bool? field.

I verified the virtual-binding semantics are correct (the C# ldvirtftn conversion makes Method.DeclaringType resolve to the most-derived override, including for grandchild types that do not re-override), so the result is right — the concern is cost and trim/AOT durability:

• Delegate.Method depends on reflection metadata being preserved for the target method. It is only consumed today from Window.Android.cs (Mono), but it is compiled into shared Microsoft.Maui.Controls code, so any future non-Android caller puts a MethodInfo lookup on a NativeAOT/full-trim path with no DynamicDependency/DynamicallyAccessedMembers anchoring it.

Suggested fix: cache by Type in a static lookup (e.g. ConditionalWeakTable<Type, ...> or a Dictionary<Type, bool> behind a lock) so the reflection runs once per page type rather than once per instance, and drop the per-instance field.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[moderate] Backward Compatibility / Regression Prevention — This rewritten comment understates the blast radius of the new early-return: the check keys off declaration of an override, not its return value, so any page that overrides OnBackButtonPressed and returns false now reports CanConsumeBackNavigation == true, enables MauiOnBackPressedCallback, and loses the Android predictive back-to-home animation (HandleBackNavigation falls through to base.OnBackPressed(), which exits without the system animation).

That is a defensible trade-off for the page that actually needs the callback, but the check is not scoped to the app's own pages — the assembly comparison matches any assembly other than Microsoft.Maui.Controls. Concrete scenario: an app whose pages all derive from a NuGet/MVVM base page class (Prism-style, or an in-house shared library) that overrides OnBackButtonPressed and mostly returns false — every page in that app now permanently loses the back-to-home animation, app-wide, with no opt-out.

Please state this explicitly in the comment (and ideally in the PR description) as a deliberate correctness-over-animation trade-off, since the current wording ("the system can safely provide the back-to-home animation for pages with framework behavior") reads as if the animation is preserved in the common case.

[MauiBot]

🔍 AI-Generated Review (multi-model)

[moderate] Regression Prevention and Test Coverage — The three added tests cover only the positive path (override present → true) and one plain negative (DerivedContentPage → false). Three discriminating cases are untested:

1. FlyoutPage whose Flyout has the override — this is the case that is actually broken (see the comment on Window.cs:832). A test here would have caught it.
2. Derived framework container without an override — e.g. class MyNav : NavigationPage {} with a single page must still return false via the stack-depth branch. Without this, a future change to HasBackButtonPressedOverride (e.g. switching from assembly comparison to GetType() != typeof(...)) would silently make every derived container claim consumption and no test would fail.
3. Override that returns false — the check is declaration-based, so this must still return true. Pinning that in a test documents the deliberate trade-off called out on Window.cs:871.

Also consider a test for a grandchild type (class C : ContentPageWithBackButtonOverride {}) that does not re-override, to lock in the virtual-resolution behavior the implementation relies on.

[MauiBot]

AI Review Summary

@jfversluis — new AI review results are available based on commit 270c687.

---

🗂️ Review Sessions — click to expand

🚦 Gate — Test Before & After Fix

Gate Result: ✅ PASSED

Platform: ANDROID · Base: main · Merge base: d48c3ba3

✅ Fix verified — 1 test(s) reproduce the bug (FAIL without the fix → PASS with it). 1 test(s) pass in both states and are not bug-reproducing; under the "at least one test reproduces the bug and none regress" rule they don't block the gate.

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🧪 WindowsTests WindowsTests	❌ PASS — 134s	✅ PASS — 137s
🖥️ Issue37706 Issue37706	✅ FAIL — 1476s	✅ PASS — 650s

🔴 Without fix — 🧪 WindowsTests: PASS ❌ · 134s

(no coded error found; showing last 1200 chars)

teWindowKeepIsActivatedIsFalse [< 1 ms]
  Passed WindowCanRetrieveDisplayDensity [4 ms]
  Passed BindingIsActivatedProperty [9 ms]
  Passed AddingTabSetsWindow [< 1 ms]
  Passed ListViewWindowIsInheritedByLayoutsInViewCells [1 ms]
  Passed NestedControlsAllHaveTheSameWindow [< 1 ms]
  Passed ActivateWindowSendAppearingOnPage [1 ms]
  Passed DetachingInTheMiddleUnsetsTheWindow [1 ms]
  Passed MovingWindowDoNotTriggerSizeChanged [< 1 ms]
  Passed ApplicationIsSetOnWindowBeforeAppearingIsCalledOnPage [< 1 ms]
  Passed SetMainPage [< 1 ms]
  Passed PageHasTheSameWindowWhenAddedLater [< 1 ms]
  Passed WindowServiceScopeHandlesNullScope [1 ms]
  Passed WindowServiceScopeWorksWithWindowCreationFlow [8 ms]
  Passed SwappingPagesUpdatesTheWindow [< 1 ms]
  Passed WindowIsStyleableWithImplicitStyle [< 1 ms]
  Passed ActivateWindowWillSetIsActiveToTrue [< 1 ms]
[xUnit.net 00:00:01.79]   Finished:    Microsoft.Maui.Controls.Core.UnitTests
  Passed DestroyedFiresDisappearingEvent [< 1 ms]
  Passed TwoKeysSameWindow [32 ms]
  Passed AddAndRemoveVisualDiagnosticAdorner [3 ms]
  Passed RemovingTabUnSetsWindow [< 1 ms]
Test Run Successful.
Total tests: 58
     Passed: 58
 Total time: 2.3235 Seconds

🟢 With fix — 🧪 WindowsTests: PASS ✅ · 137s

(no coded error found; showing last 1200 chars)

teWindowKeepIsActivatedIsFalse [< 1 ms]
  Passed WindowCanRetrieveDisplayDensity [10 ms]
  Passed BindingIsActivatedProperty [13 ms]
  Passed AddingTabSetsWindow [< 1 ms]
  Passed ListViewWindowIsInheritedByLayoutsInViewCells [1 ms]
  Passed NestedControlsAllHaveTheSameWindow [< 1 ms]
  Passed ActivateWindowSendAppearingOnPage [1 ms]
  Passed DetachingInTheMiddleUnsetsTheWindow [< 1 ms]
  Passed MovingWindowDoNotTriggerSizeChanged [1 ms]
  Passed ApplicationIsSetOnWindowBeforeAppearingIsCalledOnPage [< 1 ms]
  Passed SetMainPage [< 1 ms]
  Passed PageHasTheSameWindowWhenAddedLater [< 1 ms]
  Passed WindowServiceScopeHandlesNullScope [1 ms]
  Passed WindowServiceScopeWorksWithWindowCreationFlow [8 ms]
  Passed SwappingPagesUpdatesTheWindow [< 1 ms]
  Passed WindowIsStyleableWithImplicitStyle [< 1 ms]
  Passed ActivateWindowWillSetIsActiveToTrue [< 1 ms]
[xUnit.net 00:00:03.01]   Finished:    Microsoft.Maui.Controls.Core.UnitTests
  Passed DestroyedFiresDisappearingEvent [3 ms]
  Passed TwoKeysSameWindow [45 ms]
  Passed AddAndRemoveVisualDiagnosticAdorner [4 ms]
  Passed RemovingTabUnSetsWindow [< 1 ms]
Test Run Successful.
Total tests: 58
     Passed: 58
 Total time: 3.7832 Seconds

🔴 Without fix — 🖥️ Issue37706: FAIL ✅ · 1476s

Error-relevant lines (filtered from the build log):

     at Microsoft.Maui.TestCases.Tests.Issues.Issue37706.RootPageBackButtonOverrideIsInvokedOnce() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue37706.cs:line 24

🟢 With fix — 🖥️ Issue37706: PASS ✅ · 650s

(no coded error found; showing last 1200 chars)

.1 (x64)
Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.12]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.37]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 1 of 1 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 08/21/2026 13:35:48 FixtureSetup for Issue37706(Android)
>>>>> 08/21/2026 13:35:51 RootPageBackButtonOverrideIsInvokedOnce Start
>>>>> 08/21/2026 13:35:54 RootPageBackButtonOverrideIsInvokedOnce Stop
  Passed RootPageBackButtonOverrideIsInvokedOnce [3 s]
NUnit Adapter 4.5.0.0: Test execution complete
Results File: /home/vsts/work/1/s/CustomAgentLogsTmp/UITests/TestResults/Issue37706.trx
Test Run Successful.
Total tests: 1
     Passed: 1
 Total time: 18.3040 Seconds
>>> TRX_RESULT_FILE: /home/vsts/work/1/s/CustomAgentLogsTmp/UITests/TestResults/Issue37706.trx

⚠️ Failure Details

• ❌ WindowsTests PASSED without fix (should fail) — tests don't catch the bug

📁 Fix files reverted (2 files)

• src/Controls/src/Core/Page/Page.cs
• src/Controls/src/Core/Window/Window.cs

---

📋 Pre-Flight — Context & Validation

PR #37709 Pre-Flight

Context

• PR: [Android] Fix OnBackButtonPressed on root pages
• Issue: #37706, a regression from Microsoft.Maui.Controls 10.0.90 to 10.0.100 on Android 15/16/17.
• Expected: Pressing Android Back invokes an application override of Page.OnBackButtonPressed().
• Actual: On a root ContentPage, MAUI's OnBackPressedDispatcher callback is disabled, Android exits the app, and the override is never invoked.
• Platform: Android.
• Gate: Already passed: the detected regression test fails without the PR fix and passes with it. Do not rerun gate verification and do not alter gate/content.md.
• Base/head: main at d48c3ba39b58c724e86aca99c3823458ca1df235; PR head 270c68781cde6a407da439b3f550c4f3c0a07e55. The local review commit is a7a19e760e.

Existing PR Approach

The PR adds a cached Page.HasBackButtonPressedOverride property. It creates a typed delegate for the effective virtual OnBackButtonPressed implementation, inspects the delegate method's declaring assembly, and treats implementations outside the MAUI Controls assembly as application or third-party overrides. Window.CanConsumeBackNavigation returns true for such pages before applying its existing framework-container navigation-state checks. This preserves predictive back-to-home for framework-default pages while enabling MAUI dispatch when custom code may consume Back.

This is the approach both candidates must avoid repeating: cached delegate/reflection-based override classification on Page, followed by an early override check in Window.CanConsumeBackNavigation.

Diff Inspected

• src/Controls/src/Core/Page/Page.cs: adds cached delegate-method override detection.
• src/Controls/src/Core/Window/Window.cs: consults that detection before the existing Shell, NavigationPage, FlyoutPage, and TabbedPage state checks.
• src/Controls/tests/Core.UnitTests/WindowsTests.cs: adds coverage for a derived page without an override and custom ContentPage/NavigationPage overrides.
• src/Controls/tests/TestCases.HostApp/Issues/Issue37706.cs: root-page reproduction whose override increments visible state and consumes Back.
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue37706.cs: Android Appium regression test that presses Back, asserts exactly one invocation, and confirms the root page remains.

The PR currently changes 5 files (+122/-2). A prior review request to assert the Appium wait result has already been incorporated.

Bounded Validation Scope

Use only these targeted checks; do not run a full suite:

1. Primary Android regression test:
   pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform android -TestFilter "Issue37706"
2. Targeted navigation regressions: the five relevant Window.CanConsumeBackNavigation facts in WindowsTests (ContentPage_ReturnsFalse, DerivedContentPageWithoutOverride_ReturnsFalse, ContentPageWithBackButtonOverride_ReturnsTrue, NavigationPageWithBackButtonOverride_ReturnsTrue, and NavigationPage_SinglePage_ReturnsFalse) via the Controls Core unit-test project and an exact OR filter.

Each candidate gets one implementation/test pass and at most one focused correction/retest. A blocked device/environment phase must be recorded honestly rather than expanded into unrelated validation.

Workspace Safety

The checkout contains pre-existing dirty review-infrastructure files under .github/ and eng/. They are harness-owned and unrelated to this PR. Do not edit, restore, reset, stash, clean, or delete them. Follow the try-fix skill's script-only baseline/restore protocol and modify only paths allowed by .github/.baseline-state.json.

---

🔬 Code Review — Deep Analysis

Expert Evaluation — Submitted PR

Verdict: NEEDS_CHANGES
Confidence: medium

The submitted fix correctly restores Android back dispatch for root pages whose effective OnBackButtonPressed() implementation comes from application or third-party code. The typed delegate resolves the most-derived virtual override, the per-instance cached result is type-invariant, and the existing Android fallback still exits when an override returns false. The Gate result confirms the reported root-page regression fails without the fix and passes with it.

Actionable findings

1. Major — the same defect remains for an override on FlyoutPage.Flyout. FlyoutPage.OnBackButtonPressed() sends Back to the presented flyout before its detail, but Window.CanConsumeBackNavigation() only checks whether the flyout itself can close and then recurses into Detail. In split mode, a presented flyout page with an application override can therefore leave the Android callback disabled and never receive Back.
2. Moderate — override detection performs type-level work per page instance. Each page allocates a delegate and resolves its MethodInfo on first inspection, then stores a nullable Boolean field. A type-keyed cache would avoid repeated work and provide a clearer place to document the reflection/trim contract.
3. Moderate — the animation trade-off is understated. Detection is based on where an override is declared, not what it returns. A shared or third-party base page that overrides and commonly returns false causes all derived pages to route through MAUI and lose predictive back-to-home animation. Correct dispatch takes precedence, but the code should state that trade-off.
4. Moderate — tests omit the discriminating paths. Coverage should include the presented flyout-page override, a derived framework container without an override, an override returning false, and inherited effective override behavior.

Risk assessment

The change is localized to Android back-registration behavior but affects every page inspected by CanConsumeBackNavigation(). There is no new subscription, handler-lifetime, or mutable cross-window state. The blocking issue is the untraversed flyout recipient; the other findings are performance, durability, documentation, and regression-coverage improvements suitable for one consolidated refinement.

---

🛠️ Try-Fix — Analysis & Comparison

PR #37709 — Try-Fix Candidate 1

Result: Blocked (environment/workspace precondition — baseline could not be established without violating workspace-safety rules)

1. Problem recap

Android 15/16/17 stopped invoking an application's overridden Page.OnBackButtonPressed() on a root page after MAUI 10.0.100 moved back handling to OnBackPressedDispatcher. MauiAppCompatActivity.ShouldRegisterPredictiveBackCallback() enables MauiOnBackPressedCallback only when IBackNavigationState.CanConsumeBackNavigation is true; Window.CanConsumeBackNavigation(Page) classifies a plain/derived root ContentPage as unable to consume navigation, so the callback stays disabled and Android exits the app without ever calling the override (issue #37706).

2. Candidate 1 approach — "fail-open back dispatch with system fallback"

Designed change set (not applied — see §5):

File	Change
src/Core/src/Platform/Android/MauiAppCompatActivity.cs	Keep MauiOnBackPressedCallback.Enabled true whenever a MAUI Window is attached and at least one AndroidLifecycle.OnBackPressed delegate is registered — stop gating enablement on IBackNavigationState.CanConsumeBackNavigation.
src/Core/src/Platform/Android/MauiAppCompatActivity.cs (HandleBackNavigation)	When MAUI's dispatch chain (modal stack → Window.BackButtonPressed() → Page.SendBackButtonPressed() → Page.OnBackButtonPressed()) reports not handled, re-delegate to the platform default: temporarily set Enabled = false, re-invoke OnBackPressedDispatcher.OnBackPressed(), then restore Enabled.
src/Controls/src/Core/Window/Window.cs	CanConsumeBackNavigation is demoted from correctness gate to an animation hint only.

3. Mechanism-level difference from the PR

PR mechanism (must not be repeated): cache a typed delegate for the effective Page.OnBackButtonPressed implementation, inspect delegate.Method.DeclaringType.Assembly, expose it as Page.HasBackButtonPressedOverride, and have Window.CanConsumeBackNavigation return true early for any page whose implementation lives outside the MAUI Controls assembly.

Shared failure mechanism of that family: it retains the predict-then-enable design and merely widens the static predicate. Consumption is still guessed from type metadata before the override runs, so any page whose decision is dynamic — conditional consumption, a custom container that delegates to a child, a page that consumes only in certain states — is still classified wrongly in one direction (missed dispatch) or the other (suppressed back-to-home).

Candidate 1's mechanism and its cause-to-effect chain: prediction is removed from the correctness path entirely. Because the callback is always enabled, OnBackButtonPressed() is always invoked; because it is always invoked, its actual return value — not a type-metadata classification — determines whether the app consumed Back; because a non-consuming result explicitly re-dispatches to the system's default handler, back-to-home still happens. No reflection, no delegate/method-declaring-type inspection, and no per-Page cached classification appears anywhere in that chain. It is a different root-cause hypothesis ("prediction is the wrong model") rather than the same detection expressed in different syntax or moved to a different call site.

Honest trade-off: Android reads OnBackPressedCallback.Enabled before the predictive-back drag preview commits. An always-enabled callback therefore loses the system back-to-home preview animation for framework-default pages (commit-time behaviour remains correct via the fallback). That preview fidelity is precisely what the PR's predicate protects, so this is a real design trade-off, not a strict improvement.

Structural constraint discovered (independent of the block): the mandated targeted unit facts DerivedContentPageWithoutOverride_ReturnsFalse, ContentPageWithBackButtonOverride_ReturnsTrue, and NavigationPageWithBackButtonOverride_ReturnsTrue hard-code the PR's prediction semantics for Window.CanConsumeBackNavigation. In C#, distinguishing "this subclass overrides the virtual" from "it does not" is only expressible through type metadata — i.e. exactly the reflection/delegate-inspection family this candidate is forbidden to repeat. Therefore every genuinely different mechanism must change the prediction model, and cannot satisfy those three read-only facts unchanged. This bounds the whole alternative-candidate space for this PR and should inform candidate 2 / the final report.

4. Candidate diff

None. git diff -- src/ is empty; fix.diff and reviewer-findings.diff are 0 bytes. No tracked file was modified at any point during this invocation.

5. Why it is Blocked — baseline could not be established

Step 2 of the try-fix skill requires:

pwsh .github/scripts/EstablishBrokenBaseline.ps1

It hard-failed:

ERROR: DIRTY WORKING DIRECTORY - Cannot establish baseline
   M .github/scripts/BuildAndRunHostApp.ps1
   M .github/scripts/EstablishBrokenBaseline.ps1
   M .github/scripts/Review-PR.ps1
   ... (~40 files under .github/ and eng/) ...
EstablishBrokenBaseline.ps1 failed: Working directory is not clean.

Findings:

• The gate is git status --porcelain --untracked-files=no and is unconditional — I grepped the script for -AllowDirty / -SkipClean / $env: overrides and there is no escape hatch.
• Every dirty path is pre-existing, harness-owned review infrastructure under .github/ and eng/, unrelated to PR #37709. The invocation bounds forbid editing, reverting, staging, deleting, or otherwise altering them; the skill separately forbids git checkout/restore/reset/clean/stash. The script's own two suggested remedies (commit them, or git checkout -- .) are both prohibited.
• Because the script threw before writing state, .github/.baseline-state.json was never created. Skill Step 2 is explicit for this case: report Blocked before editing any tracked file, since the restore script can only restore files it recorded. Editing source without a baseline would also have layered a candidate on top of the PR's fix rather than replacing it, making the comparison meaningless.

Accordingly no source edit was attempted, and neither mandated validation command was run.

6. Test commands and results

Both mandated commands: NOT RUN (no candidate diff existed to validate). No broader suite was run.

1. pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform android -TestFilter "Issue37706" — NOT RUN.
2. dotnet test src/Controls/tests/Core.UnitTests/Controls.Core.UnitTests.csproj --filter "<exact OR filter over ContentPage_ReturnsFalse, DerivedContentPageWithoutOverride_ReturnsFalse, ContentPageWithBackButtonOverride_ReturnsTrue, NavigationPageWithBackButtonOverride_ReturnsTrue, NavigationPage_SinglePage_ReturnsFalse>" — NOT RUN.

Per the skill's Pass/Fail table, a Pass requires the test command to execute and report success. "The approach is sound" is never a Pass, and an unexecuted test is Blocked, not Fail. Gate verification was not rerun and gate/content.md was not touched.

7. Inline expert self-review (performed inline, no sub-agent)

reviewer-findings.json = [] — 0 findings. There is no diff, so the Overarching Principles and the always-active dimensions (Logic and Correctness, Regression Prevention, Complexity Reduction) of .github/agents/maui-expert-reviewer.md have no changed lines to bind to. No findings were invented to fill the file.

8. Failure analysis

The block is an environment/workspace precondition, not a defect in the candidate design. EstablishBrokenBaseline.ps1 assumes a pristine tree, while this worktree intentionally ships harness drift the tool cannot distinguish from leaked try-fix state. Highest-value repo follow-up: give the script a path allow-list (ignore .github/** and eng/**, or accept an -IgnorePath / $env:TRYFIX_IGNORE_DIRTY parameter) when evaluating cleanliness; otherwise every try-fix invocation in a worktree prepared like this one will block at Step 2.

9. Restoration

pwsh .github/scripts/EstablishBrokenBaseline.ps1 -Restore
→ Message: No baseline state found
→ Restored: False

This is the skill's explicitly accepted no-state outcome: baseline state was verified absent (.github/.baseline-state.json does not exist) and no attempt edits were made. Confirmed after restore:

• git status --porcelain --untracked-files=no -- src/ → empty (no candidate code changes anywhere in src/).
• The ~40 pre-existing harness-owned modifications under .github/ and eng/ remain exactly as found — untouched, unstaged, unreverted.
• Only new files created are this attempt's artifacts under CustomAgentLogsTmp/PRState/37709/PRAgent/.
• No git checkout/restore/reset/clean/stash and no filesystem deletion were used at any point.

10. Artifacts

• CustomAgentLogsTmp/PRState/37709/PRAgent/try-fix/attempt-1/ — baseline.log, approach.md, reviewer-findings.json ([]), reviewer-findings.diff (empty), result.txt (Blocked), fix.diff (empty), test-output.log, analysis.md
• CustomAgentLogsTmp/PRState/37709/PRAgent/try-fix-1/content.md — this narrative
• CustomAgentLogsTmp/PRState/37709/PRAgent/try-fix/content.md — this narrative

---

PR #37709 — Try-Fix Candidate 2

Result: Blocked — Android validation could not build because repository build tasks were absent/out of date.

Approach

Changed only the default branch of Window.CanConsumeBackNavigation(Page?) to call page.SendBackButtonPressed() and use the leaf/custom page's actual Boolean result. Framework-container branches remained state-based to avoid knowingly mutating their navigation.

Difference from both prior mechanisms

The PR caches a typed delegate, inspects its declaring assembly, and classifies override identity. Candidate 2 uses no reflection, delegate/type metadata, cache, or override classification; it directly evaluates leaf behavior. Candidate 1 proposed an always-enabled Android callback and disable/re-dispatch fallback after an unconsumed commit. Candidate 2 does neither: it retains predictive registration and obtains the leaf answer pre-gesture by executing the virtual behavior. Thus it explores behavioral evidence rather than metadata prediction or commit-time fallback.

Full candidate diff

diff --git a/src/Controls/src/Core/Window/Window.cs b/src/Controls/src/Core/Window/Window.cs
index 55d90e5025..b7db9e2304 100644
--- a/src/Controls/src/Core/Window/Window.cs
+++ b/src/Controls/src/Core/Window/Window.cs
@@ -861,10 +861,9 @@ namespace Microsoft.Maui.Controls
 					return CanConsumeBackNavigation(multiPage.CurrentPage);
 
 				default:
-					// Conservative default: return false for unknown page types.
-					// We cannot know whether a custom container's OnBackButtonPressed() returns true,
-					// so we avoid suppressing the back-to-home animation speculatively.
-					return false;
+					// Ask leaf pages directly; framework containers above are evaluated from state
+					// because invoking their back behavior here could mutate navigation.
+					return page.SendBackButtonPressed();
 			}
 		}

Exact tests/results

1. pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform android -TestFilter "Issue37706"

   Blocked before candidate compilation/test execution. The device was detected and restore succeeded, but all three script-internal build/deploy attempts failed at src/Maui.InTree.targets(34,5): “required MSBuild tasks are not yet built or they are out of date”; it requested dotnet build Microsoft.Maui.BuildTasks.slnf and exited 1. Full output: try-fix/attempt-2/test-output.log.

2. dotnet test src/Controls/tests/Core.UnitTests/Controls.Core.UnitTests.csproj --filter "FullyQualifiedName=Microsoft.Maui.Controls.Core.UnitTests.WindowsTests.ContentPage_ReturnsFalse|FullyQualifiedName=Microsoft.Maui.Controls.Core.UnitTests.WindowsTests.DerivedContentPageWithoutOverride_ReturnsFalse|FullyQualifiedName=Microsoft.Maui.Controls.Core.UnitTests.WindowsTests.ContentPageWithBackButtonOverride_ReturnsTrue|FullyQualifiedName=Microsoft.Maui.Controls.Core.UnitTests.WindowsTests.NavigationPageWithBackButtonOverride_ReturnsTrue|FullyQualifiedName=Microsoft.Maui.Controls.Core.UnitTests.WindowsTests.NavigationPage_SinglePage_ReturnsFalse"

   NOT RUN. The bounded-attempt rule requires immediate Blocked reporting/artifact completion/restoration when build or environment is blocked. No broader/substitute tests ran. Both groups did not execute/pass, so no Pass is claimed. Gate verification was not rerun; gate/content.md was untouched.

Inline expert review

Reviewed the final diff inline against all Overarching Principles, always-active Logic/Correctness, Regression Prevention, Complexity Reduction, and navigation implications. reviewer-findings.json has 2 major findings:

1. CanConsumeBackNavigation is called during appearing/navigation refreshes, so the changed line executes app behavior before a Back gesture and potentially repeatedly. Issue37706 can increment before the press and again at commit.
2. The default-only probe bypasses application overrides on framework containers; NavigationPageWithBackButtonOverride_ReturnsTrue remains unsatisfied.

No focused correction was viable without changing mechanisms: a safe pre-gesture signal that automatically tracks arbitrary overrides requires the forbidden override-metadata family; commit-time evaluation/fallback repeats Candidate 1. Invoking OnBackButtonPressed as a query is fundamentally unsafe because it is an action with side effects.

Failure analysis

The observed result is Blocked because the required command failed before compiling this hunk. Separately, review confirms the candidate is not viable. Candidate 1's structural finding holds: the mandated facts require distinguishing overridden from inherited behavior before intended invocation. Without metadata, explicit app opt-in (absent from the read-only fixtures), or always-on commit dispatch, there is no safe information source.

Restoration

Ran exactly pwsh .github/scripts/EstablishBrokenBaseline.ps1 -Restore; output reported Restored: True for Page.cs and Window.cs. Verification found no target diff and no .github/.baseline-state.json. No checkout/restore/reset/clean/stash or filesystem deletion was used.

Artifacts

/home/vsts/work/1/s/CustomAgentLogsTmp/PRState/37709/PRAgent/try-fix/attempt-2/: baseline.log, approach.md, reviewer-findings.json, reviewer-findings.diff, result.txt, fix.diff, test-output.log, analysis.md.

---

🏁 Report — Final Recommendation

⚠️ Final Recommendation: REQUEST CHANGES

Winner: pr-plus-reviewer

The submitted fix has the right core mechanism and its Gate passed, but the expert review found a concrete branch of the same regression: a presented FlyoutPage.Flyout can receive Back before Detail, while the submitted CanConsumeBackNavigation() never inspects it. The pr-plus-reviewer candidate preserves the PR's tested root-page behavior, mirrors the actual flyout dispatch order, documents the predictive-animation trade-off, and adds discriminating coverage. Its focused unit validation passed 10/10 and the Android Issue37706 regression passed 1/1.

Candidate comparison

Rank	Candidate	Evidence	Assessment
1	pr-plus-reviewer	Gate inherited from PR; focused unit tests 10/10; Android regression 1/1	Winner. Fixes the submitted root-page regression and the expert-identified split-mode flyout branch without invoking application behavior speculatively.
2	pr	Trusted Gate passed	Sound root-page fix, but it leaves a presented flyout recipient untraversed. The per-instance cache and animation trade-off are non-blocking; the flyout omission is not.
3	try-fix-1	Blocked; no diff and no tests run	The always-enabled callback design would dispatch correctly but knowingly removes predictive back-to-home preview for ordinary pages. With no implementation or regression evidence, it cannot outrank validated candidates.
4	try-fix-2	Android validation blocked; unit tests not run	Invokes SendBackButtonPressed() while merely querying navigation state, causing user side effects before a gesture and potentially repeatedly. It also misses overrides on framework containers, so it is not viable independently of the environment block.

Expert findings disposition

• Presented flyout override: fixed by checking the visible flyout before closeability and detail navigation; covered in split and hidden states.
• Behavioral trade-off: documented explicitly and covered by an override-returning-false fact.
• Effective inherited override: covered by a grandchild-page fact.
• Per-instance cache: retained as a non-blocking, unmeasured optimization opportunity; the submitted implementation computes a type-invariant value once per page and introduces no correctness failure.

Because pr-plus-reviewer, rather than the raw submitted pr, is the winning candidate, the submitted PR needs the reviewer patch before approval.

---

📱 UI Tests — Navigation,Page,Window

Detected UI test categories: Navigation,Page,Window

⚠️ Deep UI tests — 117 passed, 0 failed, 1 skipped across 3 categories on platform-pool agent (replaces in-process counts above). 1 category reported 0 tests.

🧪 UI Test Execution Results (deep, platform pool)

Category	Tests	Snapshot diffs
Navigation	91/92 (1 skipped) ✓	—
Page	26/26 ✓	—
Window	0 tests	—
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)

---

🧭 Next Steps — reviewer changes required

The reviewer-enhanced candidate identified changes that are not yet in the submitted PR.

Why: The reviewer-enhanced PR preserves the Gate-proven root-page fix while also following FlyoutPage's real dispatch order, closing the uncovered split-mode flyout override path. Its 10 focused unit tests and Android Issue37706 UI test all passed.

Address the actionable findings in this review before merging.