Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Created attachment 15527 [details]
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:
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.
1. Open attached .sln
2. Run project as is, you will notice the behavior of the FormsAppCompatActivity above
Xamarin.Forms - 184.108.40.20629
You can now set the WindowSoftInputMode with Platform Specifics (released in version 2.3.3-pre2)!
See https://github.com/xamarin/Xamarin.Forms/pull/301/commits/03ef759245c8538dd3e685fcda75dcce06d2fff8 for an example.
Xamarin Forms Team
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.
I've created an example to illustrate this bug is still active:
TestApp FormsAppCompatActivity ( (Forms 220.127.116.1129) -> bug is visible
TestApp FormsAppCompatActivity (Forms 18.104.22.168) -> bug is visible
TestApp FormsApplicationActivity (Forms 22.214.171.12429) -> 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
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
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:
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.
@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.
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 126.96.36.199 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
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).
@Jon Goldberger, I've included 2 extra sample projects for further reference on Github.
TestApp FormsApplicationActivity (Forms 188.8.131.52)
TestApp FormsApplicationActivity (Forms 184.108.40.2066-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 (220.127.116.116-pre6).
Just to add a bit of more detail, the default behavior in Android is "adjustUnspecified", 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.