Bug 39765 - WindowSoftInputMode Attribute is Ignored When Using AppCompat
Summary: WindowSoftInputMode Attribute is Ignored When Using AppCompat
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: 2.3.2
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-03-18 16:41 UTC by Jimmy [MSFT]
Modified: 2017-10-24 14:49 UTC (History)
11 users (show)

Tags: ac android softinputmode keyboard
Is this bug a regression?: ---
Last known good build:

repro project (68.93 KB, application/zip)
2016-03-18 16:41 UTC, Jimmy [MSFT]
Test Project with Jimmy's workaround (77.59 KB, application/zip)
2017-07-26 21:58 UTC, Jon Goldberger [MSFT]

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report for Bug 39765 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Jimmy [MSFT] 2016-03-18 16:41:22 UTC
Created attachment 15460 [details]
repro project

### Overview
In a Forms Android app, the WindowSoftInputMode Activity attribute is ignored because it gets reset to AdjustPan after base.Create() is called. This seems to only happen when using FormsAppCompatActivity.

### Steps to Reproduce
1. Run the attached repro project
2. Click the Editor at the bottom of the page

### Expected Results
The page should resize it’s content when the keyboard appears to fit the available space. Since the layout is wrapped in a ScrollView, you should still be able to scroll through the entire page.

### Actual Results
The page pans up to make room for the keyboard. This causes the top of the page, including the Toolbar, to appear offscreen which makes that part inaccessible while the keyboard is still open.

### Version Info
Tested with Forms

### Possible Workaround
You can programmatically change the SoftInputMode after base.OnCreate by calling

> Window.SetSoftInputMode(SoftInput.AdjustResize);

However, even though the Window is set to AdjustResize (confirmed by debugging), the page still does not work as expected. I was able to get it sort of working by also calling 

> Window.DecorView.SystemUiVisibility = 0;

but this causes the Toolbar to be shifted down below the status bar. And while the page resizes for the keyboard, it does not resize properly to its original height after the keyboard is dismissed.
Comment 1 adamm 2016-03-18 22:02:32 UTC
So I found a couple reasons that could be why the translucent status bar happens:

First, a small view is added to the global layout in the FormsAppCompatActivity to go behind the status bar. When we messed with the window flags, the window would not allow us to go behind the bar anymore, putting that view in the rest of the page.

var statusBarHeightInfo = typeof(FormsAppCompatActivity).GetField("statusBarHeight", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic);
statusBarHeightInfo.SetValue(this, 0);

if (Build.VERSION.SdkInt >= BuildVersionCodes.Kitkat)
    Window.SetStatusBarColor(new Android.Graphics.Color(ContextCompat.GetColor(this, Resource.Color.statusBarColor)));

This sets the status bar color using normal Android methods, and uses reflection to tell your bar not to draw. This results in a page where the scrolling happens correctly, but the status bar isn't screwed up.

The same effect can be found by adding different flags to Window.DecorView.SystemUiVisibility, such as SystemUiFlag.Fullscreen, but they break the scrolling again like AdjustPan does.
Comment 2 Jimmy [MSFT] 2016-08-29 20:59:11 UTC
There does appear to be an additional view added to layouts that is meant to be shown under the status bar like mentioned in comment 1. 

So putting both parts together, the complete workaround for this issue is here: https://gist.github.com/jimmgarrido/e36033b26f01e8da091fd321d41d991a
Comment 3 Jani Lirkki 2016-09-14 14:35:59 UTC
Still reproducible in latest Xamarin Forms version
Comment 4 Samantha Houts [MSFT] 2016-09-16 17:24:19 UTC
You can now set the WindowSoftInputMode with Platform Specifics (released in version 2.3.3-pre2)!

using Xamarin.Forms.PlatformConfiguration;  
using Xamarin.Forms.PlatformConfiguration.AndroidSpecific;  



See https://github.com/xamarin/Xamarin.Forms/pull/301/commits/03ef759245c8538dd3e685fcda75dcce06d2fff8 for an example.

Warm regards,
Xamarin Forms Team
Comment 5 Gerco Brandwijk 2016-12-14 11:31:13 UTC
Still not solved in Xamarin.Forms version

Or is the idea/solution that you use the Application.Current.On<Android>().UseWindowSoftInputModeAdjust(...); always, instead of using the WindowSoftInputMode property in the Activity attribute ([Activity(Theme = "@style/DefaultTheme", ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation, WindowSoftInputMode = Android.Views.SoftInput.AdjustResize)])?
Comment 6 Jon Goldberger [MSFT] 2017-07-26 20:31:43 UTC
reopening based on comment 5.

Also id does not seem that the bug was really resolved, only that a workaround was provided.
Comment 7 Jon Goldberger [MSFT] 2017-07-26 20:36:43 UTC
A more complete workaround (one for Forms 2.3.2 and below and one for Forms 2.3.3 +) was provided by Jimmy Garrido:

Comment 8 Jon Goldberger [MSFT] 2017-07-26 21:58:37 UTC
Created attachment 23829 [details]
Test Project with Jimmy's workaround


Upon closer inspection, even Jimmy's workaround does not totally resolve the issue. 

RSunning the attached test project and applying Jimmy's workaround, when I click in the Entry field and scroll the ListView, I can not scroll to the last 5 items in the list view.

## Steps to reproduce:

1. Open the newly attached test project with Jimmy's workaround

2. Run the project to an Android device or emulator (tested using Nexus 5 Lollipop emulator).

3. Scroll the ListView. You will see 15 (#0-#14) items.

4. Click on the Entry field at the bottom

5. Scroll the ListView

Expected result: can scroll to see all 15 items.

Actual result: can only scroll to see 10 items. 

Which specific 10 items you can scroll to depends on where the ListView was scrolled to when you click the Entry field. If item #1 was at the top, then you will be able to scroll to see items #1-10 on the ListView. If Item #3 was at the top, then you will be able to see items #3-12  when the keyboard is showing. (Exact behavior will likely vary with screen size)

## Environment


=== Visual Studio Enterprise 2017 for Mac ===

Version 7.0.1 (build 24)
Installation UUID: f86726f2-bd5d-4610-867e-44e82f306ca2
	Mono (2017-02/5077205) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 500010001

=== NuGet ===


=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
SDK: /usr/local/share/dotnet/sdk/1.0.1/Sdks
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.0.1/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.5.4
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 8.3.3 (12175.1)
Build 8E3004b

=== Xamarin.Android ===

Version: (Visual Studio Enterprise)
Android SDK: /Users/jongoldberger/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		4.0.3 (API level 15)
		4.1   (API level 16)
		4.2   (API level 17)
		4.3   (API level 18)
		4.4   (API level 19)
		5.0   (API level 21)
		5.1   (API level 22)
		6.0   (API level 23)
		7.0   (API level 24)
		7.1   (API level 25)

SDK Tools Version: 26.0.2
SDK Platform Tools Version: 25.0.5
SDK Build Tools Version: 26.0.0

Java SDK: /usr
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)

Android Designer EPL code available here:

=== Xamarin.iOS ===

Version: (Visual Studio Enterprise)
Hash: d2270eec
Branch: d15-2
Build date: 2017-05-22 16:30:53-0400

=== Xamarin.Mac ===

Version: (Visual Studio Enterprise)

=== Build Information ===

Release ID: 700010024
Git revision: 7ab1ca2ced6f584e56b7a0d4d321d00775cd95c9
Build date: 2017-05-19 05:44:51-04
Xamarin addins: 08d17158f3365beee5e60f67999e607cce4b3f93
Build lane: monodevelop-lion-d15-2

=== Operating System ===

Mac OS X 10.12.6
Darwin 16.7.0 Darwin Kernel Version 16.7.0
    Thu Jun 15 17:36:27 PDT 2017
    root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
Comment 9 Jon Goldberger [MSFT] 2017-07-26 22:03:43 UTC
Behavior is the same using Forms
Comment 10 Jimmy [MSFT] 2017-08-01 20:16:50 UTC
The issue in comment 8 is happening because the ListView is wrapped in a ScrollView. Using the platform specific, SoftInputMode is being set to AdjustResize. When the layout resizes, the ScrollView becomes scrollable and the scrolling gestures are being handled by the ScrollView and not the ListView. This is why we do not recommend nesting or combining ScrollViews and ListViews. 

The remaining issue is that when setting the SoftInputMode with an activity attribute instead of the platform specific it is being overridden by Xamarin.Forms. I talked to the team about this and they agreed that it is a bug that should be fixed. Therefore I am reconfirming this report in order to track this further.