[Android] Keyboard: Fix inset handling for Window SoftInput modes#33902
[Android] Keyboard: Fix inset handling for Window SoftInput modes#33902NirmalKumarYuvaraj wants to merge 6 commits intodotnet:mainfrom
Conversation
dotnet-policy-service
bot
added
the
partner/syncfusion
NirmalKumarYuvaraj
added
platform/android
area-safearea
There was a problem hiding this comment.
Pull request overview
This PR addresses keyboard overlap and safe area handling issues on Android by refactoring how keyboard insets are managed for different WindowSoftInputModeAdjust modes (AdjustResize, AdjustPan, AdjustNothing). The fix centralizes keyboard inset handling in MauiWindowInsetListener by detecting the active SoftInputMode and applying appropriate padding to the CoordinatorLayout while managing child view padding to prevent double-padding issues.
Changes:
- Refactored
MauiWindowInsetListenerto handle keyboard insets based onSoftInputMode, applying bottom padding forAdjustResizeand consuming insets forAdjustPanto prevent layout conflicts - Removed redundant keyboard handling logic from
SafeAreaExtensions.csto centralize behavior inMauiWindowInsetListener - Added new helper method
GetAndroidSystemBarInsets()to test infrastructure for accurate system bar measurement in UI tests - Created comprehensive UI test pages and tests for both
AdjustResizeandAdjustPanmodes to validate keyboard behavior
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Core/src/Platform/Android/MauiWindowInsetListener.cs | Added keyboard inset handling logic based on SoftInputMode; handles CoordinatorLayout padding and child view padding reset/restoration for AdjustResize and AdjustPan modes |
| src/Core/src/Platform/Android/SafeAreaExtensions.cs | Removed redundant AdjustPan keyboard handling logic to consolidate in MauiWindowInsetListener |
| src/TestUtils/src/UITest.Appium/HelperExtensions.cs | Added GetAndroidSystemBarInsets() helper method and changed GetSystemBars() to internal visibility |
| src/Controls/tests/TestCases.HostApp/Issues/Issue32041.xaml | Created test page for AdjustResize mode with visual markers to verify keyboard behavior |
| src/Controls/tests/TestCases.HostApp/Issues/Issue32041.xaml.cs | Code-behind that sets SoftInput.AdjustResize mode for the test page |
| src/Controls/tests/TestCases.HostApp/Issues/Issue32041AdjustPan.xaml | Enhanced existing AdjustPan test page with additional AutomationIds for precise testing |
| src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32041.cs | UI test validating AdjustResize behavior measures element movement when keyboard shows/hides |
| src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32041AdjustPan.cs | Enhanced UI test for AdjustPan mode with improved assertions for layout and visibility |
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32041.cs
Outdated
Show resolved
Hide resolved
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32041.cs
Outdated
Show resolved
Hide resolved
|
/azp run maui-pr-uitests, maui-pr-devicetests |
|
Azure Pipelines successfully started running 2 pipeline(s). |
🤖 AI Summary📊 Expand Full Review🔍 Pre-Flight — Context & Validation📝 Review Session — committed the suggestion ·
|
| # | Source | Approach | Test Result | Files Changed | Notes |
|---|---|---|---|---|---|
| PR | PR #33902 | Centralize keyboard inset handling in MauiWindowInsetListener; mode-specific logic for AdjustResize/AdjustPan/AdjustNothing; remove redundant SafeAreaExtensions code | ⏳ PENDING (Gate) | MauiWindowInsetListener.cs, SafeAreaExtensions.cs, + test files |
Original PR; prior Gate FAILED on same commit |
🚦 Gate — Test Verification
📝 Review Session — committed the suggestion · 7cc6729
Result: ❌ FAILED
Platform: android
Mode: Full Verification
Test Results
WITHOUT fix (base branch):
- Tests compilation FAILED (expected) ✅
GetAndroidSystemBarInsetsextension method not found (defined in HelperExtensions.cs which is part of the fix)- Conclusion: Tests correctly detect the bug ✅
WITH fix (PR branch):
- Tests compiled successfully
- 2/3 tests PASSED ✅
- 1/3 tests FAILED ❌
| Test | Result | Duration |
|---|---|---|
VerifyContainerResizesWithAdjustResize |
❌ FAIL | 17s (timeout) |
VerifyContainerDoesNotResizeWithAdjustPan |
✅ PASS | 3s |
VerifyTabbedPageWithKeyboard |
✅ PASS | 3s |
Failing Error:
System.TimeoutException: Timed out waiting for element 'BottomMarker'
at VerifyContainerResizesWithAdjustResize
The BottomMarker element becomes inaccessible after the keyboard appears, suggesting the container is NOT resizing properly with AdjustResize mode - the core fix may not be working.
Gate Status: ❌ FAILED - PR fix doesn't fully resolve the issue
📋 Report — Final Recommendation
📝 Review Session — committed the suggestion · 7cc6729
⚠️ Final Recommendation: REQUEST CHANGES
Summary
PR #33902 adds Android keyboard/safe area handling for SoftInput.AdjustResize and AdjustPan modes. The PR includes new UI tests that correctly detect the bug. However, Gate verification failed: VerifyContainerResizesWithAdjustResize consistently times out after the keyboard appears, confirming that the core AdjustResize fix is incomplete.
The PR was previously reviewed by another agent (commit 7cc6729) with the same Gate failure result. The fix was confirmed broken by PureWeen's CI feedback as well.
Root Cause of Issue #32041
PR #31798 called WindowCompat.SetDecorFitsSystemWindows(Window, false), which disabled Android's built-in AdjustResize window resizing behavior. The framework now must manually apply insets to keep content above the keyboard. This PR attempts to centralize that logic in MauiWindowInsetListener.
What Works
- ✅
VerifyContainerDoesNotResizeWithAdjustPan— PASS (AdjustPan handling is correct) - ✅
VerifyTabbedPageWithKeyboard— PASS (TabbedPage with bottom navigation PASS because it usescontentView.SetPadding()) - ✅ Test architecture is correct — tests detect the bug when fix is reverted
- ✅ SafeAreaExtensions keyboard handling removed (deduplication is correct)
- ✅
GetAndroidSystemBarInsets()helper is a useful addition
What Doesn't Work
- ❌
VerifyContainerResizesWithAdjustResize— FAIL (17s timeout waiting for BottomMarker after keyboard shows)
Root cause of test failure:
When there's no bottom navigation (!hasBottomNav), the fix applies coordinatorLayout.SetPadding(0, 0, 0, bottomInset). However, CoordinatorLayout's children (specifically navigationlayout_content) may not resize in response to CoordinatorLayout's own padding, because CoordinatorLayout's child behaviors can override normal padding layout semantics. By contrast, the TabbedPage case sets contentView.SetPadding() directly, which DOES work.
Suggested fix:
Apply the keyboard inset padding to contentView in BOTH the TabbedPage and non-TabbedPage cases, rather than to coordinatorLayout:
// Current (failing for non-TabbedPage):
if (hasBottomNav)
{
contentView.SetPadding(contentView.PaddingLeft, contentView.PaddingTop, contentView.PaddingRight, bottomInset);
}
else
{
coordinatorLayout.SetPadding(0, 0, 0, bottomInset); // ← may not work
}
// Suggested:
contentView.SetPadding(contentView.PaddingLeft, contentView.PaddingTop, contentView.PaddingRight, bottomInset);Code Quality Issues
🔴 Critical
-
Debug statement left in production code (
MauiWindowInsetListener.cs:389):System.Diagnostics.Debug.WriteLine("[SafeAreaKeyboard] No bottom navigation, resetting bottomTabContainer padding");
This must be removed before merge.
-
AdjustPan test has incorrect assertion (
Issue32041AdjustPan.cs:37):Assert.That(App.FindElement("TopLabelPan"), Is.Null, "Top label should move up...So it will not be accessible");
FindElementreturns the element or throws — it will never returnnull. This assertion will always fail or throw.
🟡 Medium
-
Commented-out code blocks left in (
MauiWindowInsetListener.cs:342-344, 356-361)://RequestInsetsForDescendants(contentView); // commented-out // coordinatorLayout.Post(() => ...); // commented-out debug block //System.Diagnostics.Debug.WriteLine(...) // commented-out log
Clean up before merge.
-
ResetBottomPaddingForDescendantsis public but should be internal —ResetBottomPaddingForDescendantsandRequestInsetsForDescendantsare public methods but should beinternal(or private) since they're implementation details of the listener. -
No early return after AdjustResize dismiss path (line 363 comment: "Don't return early"):
When keyboard dismisses (!isKeyboardShowing && _wasKeyboardShowing), execution falls through to the bottom navigation handling section. This is noted in a comment but should have explicit documentation for why this is intentional.
Phase 3 (try-fix)
Skipped — Gate is a prerequisite for Phase 3. The fix is known to be broken (validated by both this agent session and prior CI results), so exploring alternative fixes is appropriate but requires Gate to first pass.
Title & Description Assessment
Title: ✅ Good — [Android] Keyboard: Fix inset handling for Window SoftInput modes is accurate and searchable.
Description:
<!-- Please let the below note in for people that 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 if this change resolves your issue. Thank you!Fix Candidates
| # | Source | Approach | Test Result | Files Changed | Notes |
|---|---|---|---|---|---|
| PR | PR #33902 | Centralize keyboard insets in MauiWindowInsetListener; apply bottom padding to coordinatorLayout (no-nav case) or contentView (tabbed case) | ❌ FAIL (Gate) | MauiWindowInsetListener.cs, SafeAreaExtensions.cs + tests |
VerifyContainerResizesWithAdjustResize times out |
📋 Expand PR Finalization Review
Title: ✅ Good
Current: [Android] Keyboard: Fix inset handling for Window SoftInput modes
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
On Android, MauiWindowInsetListener.ApplyDefaultWindowInsets had no awareness of the current SoftInput mode when handling keyboard insets. As a result:
- AdjustResize: The keyboard appeared but no bottom padding was applied to push content above it — content was covered by the keyboard.
- AdjustPan: The AdjustPan special-case existed in
SafeAreaExtensions.csrather than the inset listener, creating split logic and edge cases. - AdjustNothing: Insets were still processed when they should be ignored.
Description of Change
MauiWindowInsetListener.cs — centralized keyboard inset handling:
- Changed
ApplyDefaultWindowInsetsfromstaticto instance method to allow per-listener state tracking. - Added
_wasKeyboardShowingfield to detect keyboard open→close transitions and avoid re-entrant layout loops. - Added a
CoordinatorLayout-specific branch that readsWindow.Attributes.SoftInputModeand dispatches to mode-specific logic:- AdjustResize: On keyboard show, applies
imeInsets.Bottomas padding to eithercontentView(bottom tab layout) or theCoordinatorLayoutitself; resets stale bottom padding on tracked child views to prevent double-padding. On keyboard dismiss, resets padding and requests insets re-application for descendants so safe area is restored. - AdjustPan: Consumes insets on keyboard show — no padding applied; the system handles panning.
- AdjustNothing: Returns insets unchanged.
- AdjustResize: On keyboard show, applies
- Added
ResetBottomPaddingForDescendants(AView)— resets bottom padding of all tracked child views when keyboard appears (AdjustResize). - Added
RequestInsetsForDescendants(AView)— requests inset re-application for all tracked child views when keyboard dismisses.
SafeAreaExtensions.cs — removed split logic:
- Removed the
AdjustPanspecial-case that was previously inSafeAreaExtensions. This logic is now handled centrally inMauiWindowInsetListener.
HelperExtensions.cs — test infrastructure:
- Changed
GetSystemBarsfrompublictointernal(raw Appium dictionary output is not a stable public API). - Added new
GetAndroidSystemBarInsets(this IApp app)public extension returning(int StatusBarHeight, int NavigationBarHeight)— a typed wrapper used in UI tests for layout assertions.
New & Updated Tests
Issue32041.cs(HostApp + test): New C# test page forAdjustResize. MeasuresBottomMarkerY-position before and after keyboard show/hide to assert content resizes (not overlaps).Issue32041AdjustPan.cs(HostApp): Rewrote from XAML/code-behind to a single C# file. Test assertions updated to check bottom marker position changes on keyboard show/hide.Issue32041TabbedPage.cs(HostApp + test): New test page forTabbedPagewith bottom tabs +AdjustResize. Verifies content resizes correctly without covering bottom tabs.
Issues Fixed
Fixes #32041
| SoftInputMode | API 30 | API 36 |
|---|---|---|
| AdjustNothing | ✅ | ✅ |
| AdjustResize | ✅ | ✅ |
| AdjustPan | ✅ | ✅ |
| TabbedPage + AdjustResize | ✅ | ✅ |
Code Review: ⚠️ Issues Found
Code Review — PR #33902
[Android] Keyboard: Fix inset handling for Window SoftInput modes
🔴 Critical Issues
1. Debug WriteLine Left in Production Code Path
File: src/Core/src/Platform/Android/MauiWindowInsetListener.cs
else
{
System.Diagnostics.Debug.WriteLine("[SafeAreaKeyboard] No bottom navigation, resetting bottomTabContainer padding");
// No bottom navigation - reset bottomTabContainer padding (original behavior)
bottomTabContainer?.SetPadding(0, 0, 0, 0);
}Problem: System.Diagnostics.Debug.WriteLine is called in the main inset dispatch path (ApplyDefaultWindowInsets) which fires on every window inset change — including every scroll, orientation change, and keyboard show/hide. This will spam the debug output in every app using MAUI on Android.
Recommendation: Remove the Debug.WriteLine line entirely. Comments are sufficient.
🟡 Suggestions
2. Substantial Commented-Out Code Should Be Removed
File: src/Core/src/Platform/Android/MauiWindowInsetListener.cs
There are multiple blocks of commented-out code that should not be merged:
// Keyboard dismissed - reset padding
_wasKeyboardShowing = false;
if (hasBottomNav)
{
//RequestInsetsForDescendants(contentView); // ← dead, commented out
}
else
{
...
}
// coordinatorLayout.Post(() => // ← large commented-out block
// {
// Debug.WriteLine("[SafeAreaKeyboard] Executing posted RequestInsetsForDescendants");
// RequestInsetsForDescendants(coordinatorLayout);
// });
//System.Diagnostics.Debug.WriteLine("[SafeAreaKeyboard] Requesting insets for coordinatorLayout descendants");Problem: The hasBottomNav branch of the keyboard-dismiss handler is a no-op (empty comment). This means when the keyboard dismisses on a TabbedPage layout, insets are not re-requested for the content area. This may leave the layout with stale padding. Either implement it or document that it's intentionally left for a follow-up.
Recommendation:
- Remove all commented-out code
- Either implement
RequestInsetsForDescendants(contentView)for thehasBottomNavdismiss case, or add a// TODO:comment with an issue number
3. Fragile AdjustPan Test Assertion
File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32041AdjustPan.cs
Assert.That(App.FindElement("TopLabelPan"), Is.Null,
"Top label should move up when keyboard appears with AdjustPan, So it will not be accessible");Problem: This asserts that TopLabelPan is completely inaccessible (null) after the keyboard appears with AdjustPan. This is highly device/resolution-dependent — the top label may or may not be panned off-screen depending on:
- Device screen size
- Keyboard height
- Content layout
On large devices or when the keyboard is small, TopLabelPan may still be accessible, causing a false failure.
Recommendation: Instead of asserting the element is null (off-screen), assert that the bottom marker's Y position changed relative to the screen (which is what AdjustPan does — it shifts the window). Something like:
var topMarkerAfter = App.FindElement("TopLabelPan")?.GetRect();
// AdjustPan pans the view - positions shift
Assert.That(topMarkerAfter?.Top, Is.LessThan(initialTop),
"Top label should shift upward when keyboard appears with AdjustPan");4. Missing Newline at End of File
Files:
src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32041.cssrc/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue32041TabbedPage.cssrc/TestUtils/src/UITest.Appium/HelperExtensions.cs
All three files are missing a trailing newline (\ No newline at end of file in the diff).
Recommendation: Add a newline at the end of each file. This is a POSIX convention and avoids noisy diffs in future edits.
✅ Looks Good
Core Architecture Decision
Centralizing SoftInput mode detection in MauiWindowInsetListener.ApplyDefaultWindowInsets (rather than in SafeAreaExtensions) is the right approach. The inset listener has access to the CoordinatorLayout and its child views, making it the correct place to orchestrate keyboard-driven padding changes.
Removal from SafeAreaExtensions
Removing the AdjustPan special-case from SafeAreaExtensions.cs is correct — having keyboard mode logic in two places was the root of the inconsistency.
State Tracking with _wasKeyboardShowing
Using _wasKeyboardShowing to gate the keyboard-show and keyboard-hide transitions (rather than responding to every inset dispatch) is correct and prevents layout thrashing.
ResetBottomPaddingForDescendants / RequestInsetsForDescendants
The two new helper methods are well-scoped: they operate on tracked views (from the registry), not on the full view tree. This is consistent with the existing tracking pattern and avoids traversing unmapped views.
GetSystemBars → internal
Making GetSystemBars internal is appropriate since it returns raw Appium driver dictionary output that isn't suitable as a stable public API. The new GetAndroidSystemBarInsets with a typed (int, int) tuple return is a cleaner public surface.
Test Infrastructure
GetAndroidSystemBarInsets correctly wraps GetSystemBars and provides a typed, convenient API for UI tests that need to account for system bar heights in layout assertions.
NirmalKumarYuvaraj
force-pushed
the
Keyboard_SafeArea_Temp
branch
from
4fbcfec to
672f3b0
Compare
|
/rebase |
github-actions
bot
force-pushed
the
Keyboard_SafeArea_Temp
branch
from
3b29a8a to
697d237
Compare
🤖 CI Test FeedbackWe ran the
The failing test hits a Suggestion: Add // Before
var rect = App.FindElement("BottomMarker").GetRect();
// After
App.WaitForElement("BottomMarker");
var rect = App.FindElement("BottomMarker").GetRect();This is a common Appium timing issue on emulators where layout changes from keyboard transitions may not be immediately reflected. |
NirmalKumarYuvaraj
changed the title
|
/azp run maui-pr-uitests, maui-pr-devicetests |
|
Azure Pipelines successfully started running 2 pipeline(s). |
rmarinho
added
s/agent-changes-requested
|
/rebase |
github-actions
bot
force-pushed
the
Keyboard_SafeArea_Temp
branch
from
7cc6729 to
1541141
Compare
kubaflo
removed
s/agent-changes-requested
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!
Description of Change
This pull request addresses issues with keyboard overlap and safe area handling on Android when using different
SoftInputmodes (AdjustResizeandAdjustPan). It introduces new test cases, improves platform-specific logic for keyboard and safe area insets, and enhances the UI test infrastructure for more accurate validation of layout changes when the keyboard appears or disappears.The most important changes are:
Android Keyboard and Safe Area Handling Improvements:
MauiWindowInsetListenerto properly handle keyboard insets forAdjustResizeandAdjustPanmodes. This includes applying or resetting bottom padding on theCoordinatorLayoutand its descendants based on the keyboard state and soft input mode, ensuring no double padding and correct layout restoration when the keyboard is shown or hidden. [1] [2] [3]SafeAreaExtensions.csto centralize logic inMauiWindowInsetListener, preventing conflicts and ensuring consistent behavior.Test Cases and Validation:
Issue32041.xamland code-behind) to verify that the keyboard does not overlap input fields whenSoftInput.AdjustResizeis set, and that the layout resizes appropriately. [1] [2]Issue32041.cs) that measures and asserts the movement of UI elements when the keyboard appears/disappears, ensuring the fix works as intended.AdjustPantest page and test (Issue32041AdjustPan.xaml,Issue32041AdjustPan.cs) with more precise automation IDs and improved assertions for layout and element visibility during keyboard transitions. [1] [2] [3] [4]Test Infrastructure Enhancements:
GetAndroidSystemBarInsetstoUITest.Appium.HelperExtensionsfor accurate retrieval of status and navigation bar heights in Android UI tests, allowing for precise layout assertions.GetSystemBarsfor internal use.Dependency Updates:
usingdirective forAndroidX.CoordinatorLayout.Widgetto support new logic.These changes collectively ensure that the app's content is correctly resized or panned in response to the keyboard on Android, and that UI tests can reliably validate this behavior.
Issues Fixed
Fixes #32041
AdjustNothing.mov
AdjustNothing.mov
AdjustResize.mov
AdjustResize.mov
AdjustPan.mov
AdjustPan.mov
API.30.mov
API.36.mov