Bug 39916 - SoftKeyboard default behavior covers Listview when using FormsAppCompatActivity.
Summary: SoftKeyboard default behavior covers Listview when using FormsAppCompatActivity.
Status: RESOLVED INVALID
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: 2.1.0
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-03-25 18:20 UTC by Jon Douglas [MSFT]
Modified: 2017-08-03 00:46 UTC (History)
7 users (show)

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


Attachments
FormsAppCompatActivity (230.55 KB, application/x-zip-compressed)
2016-03-25 18:20 UTC, Jon Douglas [MSFT]
Details


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 on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED INVALID

Description Jon Douglas [MSFT] 2016-03-25 18:20:34 UTC
Created attachment 15527 [details]
FormsAppCompatActivity

*Description:

The default functionality of the softkeyboard has seemed to change between FormsApplicationActivity and FormsAppCompatActivity.

See the following behaviors:

FormsApplicationActivity - http://screencast.com/t/llUrBCW8

The keyboard does not cover any elements in a ListView.

FormsAppCompatActivity - http://screencast.com/t/AvnwNs6b0lfb

The keyboard covers the existing elements in a ListView thus, one cannot effective navigate to the last few items in the ListView

I believe this might be a limitation of the respective android:windowSoftInputMode(http://developer.android.com/guide/topics/manifest/activity-element.html#wsoft) that is provided in FormsAppCompatActivity

Specifically AppCompat adds the following:

Window.SetSoftInputMode (SoftInput.AdjustPan);

The activity's main window is not resized to make room for the soft keyboard. Rather, the contents of the window are automatically panned so that the current focus is never obscured by the keyboard and users can always see what they are typing. This is generally less desirable than resizing, because the user may need to close the soft keyboard to get at and interact with obscured parts of the window.

*Reproduction:

1. Open attached .sln
2. Run project as is, you will notice the behavior of the FormsAppCompatActivity above

*Related Bugs:

https://bugzilla.xamarin.com/show_bug.cgi?id=39765

https://bugzilla.xamarin.com/show_bug.cgi?id=37202

*Version Information

Xamarin.Forms - 2.1.0.6529
Comment 1 Samantha Houts [MSFT] 2016-09-16 17:24:43 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;  

...

Application.Current.On<Android>().UseWindowSoftInputModeAdjust(...);


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

Warm regards,
Xamarin Forms Team
Comment 2 HRO Jordy 2016-12-08 09:54:51 UTC
@Samantha Houts

How is this a fix for the described bug? Without FormsAppCompatActivity the behaviour of the keyboard and the listview is correct. With the FormsAppCompatActivity this behavior is broken. I do not want to manually correct this as your fix proposes, this should be default behavior, like when you do not use the FormsAppCompatActivity.
Comment 3 HRO Jordy 2016-12-15 09:07:43 UTC
I've created an example to illustrate this bug is still active:

https://we.tl/301raA3Fya
contains: 
TestApp FormsAppCompatActivity ( (Forms 2.1.0.6529) -> bug is visible
TestApp FormsAppCompatActivity (Forms 2.3.3.175) -> bug is visible
TestApp FormsApplicationActivity (Forms 2.1.0.6529) -> behaves as expected

As discussed in this forum post a workaround is applicable for older versions of Xamarin Forms with AppCompat: https://forums.xamarin.com/discussion/comment/239923
which contains of 2 fixes
- set the WindowsSoftInputMode to AdjustResize, but setting this breaks the statusbar
- so another fix is applied to fix the statusbar

In Xamarin Forms 2.3.3 this workaround does not work anymore. And I think the solution Samantha Houts suggests is the same workaround, just typed differently.
- using this code

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

Xamarin.Forms.Application.Current.On<Android>().UseWindowSoftInputModeAdjust(WindowSoftInputModeAdjust.Resize);

breaks the status bar again.

Also AppCompat does not respect the WindowsSoftInputMode when set in the Activity attribute (like this):

[Activity(Label = "AppName", Icon = "@drawable/icon", MainLauncher = false, ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation, WindowSoftInputMode = Android.Views.SoftInput.AdjustResize)]
public class MainActivity : XLabs.Forms.XFormsAppCompatDroid
Comment 4 Jon Goldberger [MSFT] 2017-07-26 20:34:53 UTC
Setting status as reopened based on comments 2 and 3.

Also it does not seem that the bug was really resolved, only that a workaround was provided.

And perhaps a more complete workaround (one for Forms 2.3.2 and below and one for Forms 2.3.3 +) was provided by Jimmy Garrido:

https://gist.github.com/jimmgarrido/e36033b26f01e8da091fd321d41d991a
Comment 5 Jon Goldberger [MSFT] 2017-07-26 20:59:30 UTC
Actually, running the attached test project I am seeing the same behavior for FormsApplicatoinActivity and FormsAppCompatActivity now,  and in both cases the bottom of the list view is covered up when the keyboard appears. 

The new test project mentioned in comment 3 has been removed from the link, so I can not verify whta was described in coment 3.
Comment 6 HRO Jordy 2017-07-27 07:58:15 UTC
@Jon Goldberger: I've added the 3 projects to GitHub. I've also added the zip files to this repository in case there was an uploading problem with the code.

https://github.com/Knordy/TestApps-for-Xamarin-bug-39916
Comment 7 Jon Goldberger [MSFT] 2017-07-27 20:43:05 UTC
@HRO Jordy,

thanks for providing that. The version with Forms 2.3.3 seems identical to the original test project provided with the different version of Forms.

Since I don't really care much about the behavior of past versions of Forms, I updated to the latest stable 2.3.4.247 before doing anything else. 

Here is what I found: Yes, the ListView is covered partly when the Entry is selected. Using FormsApplicationActivity made no difference. Using the 
>App.Current.On<Xamarin.Forms.PlatformConfiguration.Android>().UseWindowSoftInputModeAdjust(WindowSoftInputModeAdjust.Resize);
made no difference either whether using the FormsApplicationActivity or FormsAppCompatActivity.

OK, then I see that your entry was at the top and was not about to be covered by the keyboard. I have to check native android, but in this case I don't believe the Android OS will do anything. If I move the Entry to the bottom, under the ListView, then I get the behavior as described in bug 39765. IOW without the workaround, I can only scroll to some but not all of the listView items. This is true regardless of using FormsApplicationActivity or FormsAppCompatActivity. In other words it seems the WindowSoftInputMode property of the Activity Attribute is indeed ignored, but it is always ignored as far as I can tell. Or as noted in the other bug report that it is reset after base.OnCreate is called. 

At this time I think that the exact issue in this bug is invalid. IOW because the Entry was not in danger of being covered by the keyboard, no action is taken by the OS, i.e. no panning or resizing will occur unless the Entry is going to be covered by the keyboard. 

I am going to mark this particular bug as RESOLVED INVALID. 

I think the underlying issue is bug 39765 that the WindowSoftInputMode property of the Activity attribute is ignored (for both FormsApplicationActivity and FormAppCompatActivity).
Comment 8 HRO Jordy 2017-07-28 09:01:55 UTC
@Jon Goldberger, I've included 2 extra sample projects for further reference on Github.

TestApp FormsApplicationActivity (Forms 2.3.4.247)
TestApp FormsApplicationActivity (Forms 2.3.5.256-pre6)

As you already mentioned it seems the bug is now also active without FormsAppCompat. I can confirm it is still active in the latest pre-release (2.3.5.256-pre6).
Comment 9 Jimmy [MSFT] 2017-08-01 19:52:44 UTC
Just to add a bit of more detail, the default behavior in Android is "adjustUnspecified"[1], however Xamarin.Forms does set it to AdjustPan by default on both FormsApplicationActivity and FormsAppCompatActivity now unless you use the platform specific from comment 1. 

I talked with the team and they agreed that we should not be ignoring the value from the Activity attribute as Jon mentioned in comment 7. That issue will be tracked with bug 39765. However once that is fixed, the default setting when no attribute or platform specific is provided should be "adjustUnspecified" so you will still have to manually set it to AdjustResize regardless.

[1] https://developer.android.com/guide/topics/manifest/activity-element.html#wsoft