[Android] Fix for TabbedPage BottomNavigation BarBackgroundColor not extending to system navigation bar

[praveenkumarkarunanithi]

Root Cause

In Android Edge-to-Edge mode, the MauiWindowInsetListener was applying padding to the root view and consuming bottom insets. This prevented BottomNavigationView from receiving the system navigation bar insets, so it could not extend its background color into the navigation bar area—resulting in a visible gap between the tab bar and the screen edge.

Description of Change

When a TabbedPage uses ToolbarPlacement.Bottom, the fix applies bottom padding to contentView (the fragment container) instead of the root view, and passes bottom insets through without consuming them. This allows BottomNavigationView to receive the insets and extend its background color into the system navigation bar area, eliminating the gap.

Issues Fixed

Fixes #33344

Tested the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Note:
This issue is Android-specific. Windows and macOS do not have a system navigation bar area at the bottom of the screen.

Screenshots

Before Issue Fix	After Issue Fix

[sheiksyedm]

/rebase

[Copilot]

Pull request overview

This PR fixes an Android edge-to-edge mode issue where TabbedPage with ToolbarPlacement.Bottom did not extend the BarBackgroundColor into the system navigation bar area, leaving a visible gap. The fix changes how window insets are handled in MauiWindowInsetListener to apply bottom padding to the content view instead of the root view, and passes bottom insets through unconsumed so that BottomNavigationView can extend into the navigation bar area.

Changes:

• Modified inset handling logic to apply bottom padding to content view instead of root view when bottom navigation is present
• Removed appBarHasContent condition from inset consumption to allow SafeAreaExtensions overlap logic to handle padding correctly
• Added a test to verify BottomNavigationView extends to screen bottom in edge-to-edge mode

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/Core/src/Platform/Android/MauiWindowInsetListener.cs	Modified inset handling to pad content view instead of root view for bottom navigation, and pass through bottom insets unconsumed
src/Controls/tests/DeviceTests/Elements/TabbedPage/TabbedPageTests.Android.cs	Added test to verify bottom navigation view extends to screen bottom with proper layout positioning

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Merge branch 'fix-33344' of https://github.com/praveenkumarkarunanithi/maui into fix-33344 · f614303

---

Issue: #33344 - TabbedPage BottomNavigation BarBackgroundColor does not extend to system navigation bar area in Edge-to-Edge mode
Platforms Affected: Android (Android 15 / API 35+)
Milestone: .NET 10 SR5
Labels: platform/android, , partner/syncfusion, area-safeareacommunity
Files Changed: 1 fix file, 1 device test file

Issue Summary

In .NET MAUI 10 on Android 15 (API 35+), when using TabbedPage with ToolbarPlacement.Bottom, the BarBackgroundColor does not extend into the system navigation bar area (gesture bar / 3-button nav). This is a regression introduced in 10.0.0-rc.1 when Edge-to-Edge was enabled by default.

Root Cause (from PR)

MauiWindowInsetListener.ApplyDefaultWindowInsets was applying padding to the root view and consuming bottom insets (setting them to 0 in the returned WindowInsetsCompat). This prevented BottomNavigationView from receiving system navigation bar insets, so it could not extend its background into the nav bar area.

Files Changed

File	Type	Lines
src/Core/src/Platform/Android/MauiWindowInsetListener.cs	Fix	+19 / -8
src/Controls/tests/DeviceTests/Elements/TabbedPage/TabbedPageTests.Android.cs	Device Test	+43 / 0

PR Fix Summary

When hasBottomNav is true (TabbedPage with ToolbarPlacement.Bottom):

1. Before: Padded root view with bottom inset only; consumed bottom insets (set to 0 in returned insets)
2. After: Pads contentView with left, right, bottom system bar insets; passes ALL insets through unconsumed

Additional change: Removed appBarHasContent conditional from newSystemBars/newDisplayCutout construction, now always passing top insets through unconsumed.

Prior Agent Review Status

A prior agent review was posted to the PR. Gate FAILED in the prior run. The author has NOT updated the code since then (same commit SHA f614303).

Reviewer Comments (Copilot PR Reviewer - unresolved)

File:Line	Concern	Status
MauiWindowInsetListener.cs:281	Left/right insets on contentView may conflict with CoordinatorLayout NOT ADDRESSED	behavior
MauiWindowInsetListener.cs:276	Comment should clarify padding covers nav bar + system nav NOT ADDRESSED	bar
TabbedPageTests.Android.cs:250	Exact equality (==) for pixel positions is NOT ADDRESSED	fragile

Key Concerns

1. Left/right insets on contentView (Medium): Adds systemBars?.Left and systemBars?.Right to contentView not in original code and may cause double-padding in landscape mode.padding
2. Removed appBarHasContent conditional (Medium): Top insets now ALWAYS passed through; this is unrelated to the bottom nav fix and could affect NavigationPage/Shell with top navigation bars.
3. Test uses exact equality (Minor): screenHeight == bottomNavBottom should use Math.Abs(...) < 2 for robustness.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33428	Pad contentView instead of root view; pass all insets through PENDING (Gate)	MauiWindowInsetListener.cs (+19/-8)	Original PR - 3 unaddressed review comments	unconsumed

---

🚦 Gate — Test Verification

---

📝 Review Session — Merge branch 'fix-33344' of https://github.com/praveenkumarkarunanithi/maui into fix-33344 · f614303

---

** FAILEDResult:**
Platform: android
Mode: Full Verification (Two-Pass)

Gate Verification Results

Pass	State	Expected	Actual	Status
Pass 1 (WITHOUT fix)	Fix reverted to origin/main	FAIL	FAIL OK
Pass 2 (WITH fix)	Fix applied	PASS	BAD	FAIL

Critical Finding: Test Does Not Pass With Fix Applied

The test BottomNavigationViewExtendsToScreenBottom failed in both passes:
Failed WITHOUT the fix (Pass 1 - "expected", but for wrong reason)-
Failed WITH the fix (Pass 2 - unexpected)-

Root Cause of Gate Failure

The test BottomNavigationViewExtendsToScreenBottom is located in the DeviceTests project:
src/Controls/tests/DeviceTests/Elements/TabbedPage/TabbedPageTests.Android.cs

The Gate verification uses BuildAndRunHostApp.ps1 which builds and runs the UI Test HostApp (TestCases.HostApp). Device tests are a completely separate project that runs via Helix on CI they cannot be run locally using the HostApp runner.infrastructure

The build succeeded (0 errors) but no tests matching the filter were executed because the test isn't in the HostApp project.

Environment Blocker: Device tests require Helix infrastructure (cloud-based device testing) to they cannot be verified locally with the available test scripts.run

Prior Review Corroboration

The prior agent review (same commit f614303) also found Gate FAILED, describing the test as "passing both with and without the fix" in that environment. This is consistent - in both environments, the Gate infrastructure cannot properly verify this device test.

Gate Status

** FAILED**GATE:

Fix phase (try-fix) skipped: Cannot explore alternative fixes without a reliable local test to verify against.

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Merge branch 'fix-33344' of https://github.com/praveenkumarkarunanithi/maui into fix-33344 · f614303

---

Fix Phase: Skipped - Gate Failed

Reason: Phase 3 (try-fix) was skipped because Gate failed.

The test BottomNavigationViewExtendsToScreenBottom is a device test that runs via Helix infrastructure (not locally via the HostApp runner). Without a reliable local test to validate fix candidates against, try-fix exploration cannot be performed.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #33428	Pad contentView instead of root view; pass all insets through UNVERIFIED (Gate failed)	MauiWindowInsetListener.cs (+19/-8)	Test doesn't run locally	unconsumed

Exhausted: N/A (skipped due to Gate failure - environment blocker)
Selected Fix: N/A - Cannot select without reliable tests

---

📋 Report — Final Recommendation

---

📝 Review Session — Merge branch 'fix-33344' of https://github.com/praveenkumarkarunanithi/maui into fix-33344 · f614303

---

Final Recommendation: REQUEST CHANGES##

Summary

PR #33428 addresses a real regression in .NET MAUI 10 where TabbedPage with ToolbarPlacement.Bottom doesn't extend BarBackgroundColor into the system navigation bar area on Android 15+ in Edge-to-Edge mode. The core fix direction (padding contentView instead of the root view, passing insets through unconsumed) is correct in principle. However, the PR has three significant technical issues plus a test verification problem that require the author's attention before it can be merged.

Root Cause Analysis

In Android Edge-to-Edge mode (API 35+), MauiWindowInsetListener.ApplyDefaultWindowInsets was applying bottom padding to the root view and consuming bottom insets (setting them to 0 in the returned WindowInsetsCompat). Since BottomNavigationView never received the system navigation bar insets, it could not extend its background color into the navigation bar leaving a visible gap between the tab bar and the screen edge.area

Gate Verification

• Platform tested: Android
• Test: BottomNavigationViewExtendsToScreenBottom in TabbedPageTests.Android.cs (DeviceTests)
• Gate Environment blocker: the test is a device test (Helix infrastructure) and cannot be verified locally via the HostApp runner. Both passes failed, consistent with the prior agent review which also found Gate FAILED.FAILED status:

Fix Analysis

Change	Assessment	Verdict
Pad instead of root view	prevents content area from being squished by the system nav bar	Correct Good
Pass bottom insets through unconsumed	allows to extend its background into nav bar area	Required Good
Apply left/right insets to contentView	Not needed for the fix; may cause unexpected padding in landscape mode with Remove	cutouts
Remove appBarHasContent from top insets	Unrelated change; changes inset behavior for ALL layouts (NavigationPage, Shell); regression Revert	risk
Test uses exact equality for pixel positions	Fragile; 1px rounding differences common on Fix	Android

Required Changes

Issue 1 (Critical): Test does not reliably verify the fix

The test BottomNavigationViewExtendsToScreenBottom measures whether BottomNavigationView's bottom pixel coordinate equals the screen height. In Edge-to-Edge mode, BottomNavigationView is often already laid out to the physical screen bottom regardless of inset the visual gap is caused by the background color not extending, not by the view's position being different.state

A more reliable test would:

• Verify that contentView's bottom padding equals the system navigation bar inset height when hasBottomNav is true
• OR verify that the root view does NOT have bottom padding in the bottom-nav scenario

Issue 2 (Medium): Remove left/right insets from contentView padding

The original code only applied bottom padding to the root view. The fix introduces left/right insets on contentView which:

1. Are not needed for the bug fix
2. Were not in the original code
3. May cause unexpected behavior in landscape orientation with display cutouts

// Change this:
contentView?.SetPadding(
    systemBars?.Left ?? 0,
    0,
    systemBars?.Right ?? 0,
    bottomInset);

// To this:
contentView?.SetPadding(0, 0, 0, bottomInset);

Issue 3 (Medium): Revert the appBarHasContent inset consumption change

Removing the appBarHasContent ? 0 : systemBars?.Top ?? 0 conditional changes behavior for all layouts, not just TabbedPage bottom navigation. This is unrelated to the bug fix, was not explained in the PR description, and has no accompanying tests for NavigationPage/Shell scenarios.

// Revert to original:
var newSystemBars = Insets.Of(
    systemBars?.Left ?? 0,
    appBarHasContent ? 0 : systemBars?.Top ?? 0,
    systemBars?.Right ?? 0,
    hasBottomNav ? 0 : systemBars?.Bottom ?? 0
) ?? Insets.None;

Issue 4 (Minor): Test tolerance

// Change:
Assert.True(screenHeight == bottomNavBottom, ...);
// To:
Assert.True(Math.Abs(screenHeight - bottomNavBottom) < 2, ...);

Prior Review Status

This is the second agent review of this PR. The prior review (posted 2026-02-17) made the same recommendations. The author has NOT addressed any of the concerns since the review was posted (same commit SHA f614303).

There are also 3 unresolved inline review comments from the Copilot PR Reviewer (Jan 16, 2026) that align with findings none have been addressed.above

---

📋 Expand PR Finalization Review

---

Title: ✅ Good

Current: [Android] Fix for TabbedPage BottomNavigation BarBackgroundColor not extending to system navigation bar

Description: ✅ Good

Description needs updates. See details below.

✨ Suggested PR Description

[!NOTE]
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Root Cause

In Android Edge-to-Edge mode, the MauiWindowInsetListener was applying padding to the root view and consuming bottom insets. This prevented BottomNavigationView from receiving the system navigation bar insets, so it could not extend its background color into the navigation bar area—resulting in a visible gap between the tab bar and the screen edge.

Description of Change

When a TabbedPage uses ToolbarPlacement.Bottom, the fix applies bottom padding to contentView (the fragment container) instead of the root view, and passes bottom insets through without consuming them. This allows BottomNavigationView to receive the insets and extend its background color into the system navigation bar area, eliminating the gap. Additionally, removed the appBarHasContent check from inset consumption since SafeAreaExtensions overlap logic already correctly determines padding for child views based on their screen position.

Issues Fixed

Fixes #33344

Tested the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Note:
This issue is Android-specific. Windows and macOS do not have a system navigation bar area at the bottom of the screen.

Screenshots

Before Issue Fix	After Issue Fix

Code Review: ✅ Passed

Code Review Findings — PR #33428

🟡 Suggestions

1. Test assertion uses exact pixel equality — could be fragile

File: src/Controls/tests/DeviceTests/Elements/TabbedPage/TabbedPageTests.Android.cs

Code:

Assert.True(screenHeight == bottomNavBottom,
    $"BottomNavigationView should extend to screen bottom. Expected bottom at {screenHeight}px, but was at {bottomNavBottom}px (gap of {screenHeight - bottomNavBottom}px)");

Problem: Pixel-exact equality (==) between BottomNavigationView's bottom and the DecorView's height may fail due to sub-pixel rounding or density differences on some devices/emulators.

Recommendation: Use a small tolerance (e.g., ±1px) to avoid flakiness:

var gap = screenHeight - bottomNavBottom;
Assert.True(Math.Abs(gap) <= 1,
    $"BottomNavigationView should extend to screen bottom. Expected bottom at {screenHeight}px, but was at {bottomNavBottom}px (gap of {gap}px)");

Or use Assert.Equal(screenHeight, bottomNavBottom) for a cleaner failure message without the tolerance concern.

---

2. Reconstructed Insets are identical to originals — effectively a pass-through

File: src/Core/src/Platform/Android/MauiWindowInsetListener.cs

Code (lines 291–308):

var newSystemBars = Insets.Of(
    systemBars?.Left ?? 0,
    systemBars?.Top ?? 0,
    systemBars?.Right ?? 0,
    systemBars?.Bottom ?? 0
) ?? Insets.None;

var newDisplayCutout = Insets.Of(
    displayCutout?.Left ?? 0,
    displayCutout?.Top ?? 0,
    displayCutout?.Right ?? 0,
    displayCutout?.Bottom ?? 0
) ?? Insets.None;

Observation: After the fix, newSystemBars and newDisplayCutout are now exact copies of the original values (no values are consumed/zeroed). The Insets reconstruction code is logically equivalent to passing insets unchanged. This isn't a bug, but it's unnecessary complexity that makes the code harder to reason about.

Recommendation (low priority): Simplify to just pass through the original insets:

// Previously consumed certain insets; now all passed through as SafeAreaExtensions handles positioning
return insets;

This makes the intent explicit and eliminates the dead Insets-construction code. However, this is purely cosmetic and can be left for a follow-up cleanup.

---

✅ Looks Good

• Core fix approach is correct: Moving bottom padding from the root view to contentView is the right Android pattern. The root view consuming bottom insets was the root cause of BottomNavigationView not being able to extend into the gesture bar area.

• Removal of appBarHasContent from inset forwarding is justified: The AppBarLayout already applies its own top padding directly (appBarLayout.SetPadding(...)). Consuming top insets in the forwarded values was redundant since SafeAreaExtensions uses screen-position-based overlap detection rather than relying on consumed insets. Passing insets through avoids over-consuming them for child views.

• contentView padding includes horizontal insets: The new content-view padding (contentView?.SetPadding(systemBars?.Left ?? 0, 0, systemBars?.Right ?? 0, bottomInset)) correctly includes left/right side insets — an improvement over the old root-view padding that only handled bottom (v.SetPadding(0, 0, 0, bottomInset)).

• Null-safe content view reset: The else branch resets contentView?.SetPadding(0, 0, 0, 0) to handle the case where bottom navigation is dynamically removed.

• Test is well-structured: The test correctly verifies the end-to-end behavior (BottomNavigationView reaching the screen bottom) rather than just testing an internal API, providing good regression coverage.

---

[kubaflo]

Hi @praveenkumarkarunanithi what do you think about the suggestions from AI Summary