Open VishalOmprasad opened 8 months ago
Recognized that the different (redurced height) screen size is being returned by Page.SizeChanged in my project. The behaviour changed from android 9 to 10? when it started to return new size values when activating the keyboard. My project had AdjustNothing enabled for the activity. I saw somewhere in the android documentation google pointed out there are new sources for the screen coordinated to be used.
This is a regression. This used to work, not anymore. Huge showstopper basically.
We will not be able to hack this because the keyboard is part of the OS, it basically reduced the window size of the app which should be "propagated" downwards like WPF always does. This bug (WPF must be told to resize if kbd pops up or down) might be from the android API as this is one of WPFs core strengths which I have never seen violated before. WPF always reacts to main window size changes immediately! You cannot use the keyboard in Maui anymore at the moment because of this. Nobody seems to be using the platform.
Right now, the keyboard pushes the entire app screen out of bounds at the top. Even if we got a keyboard event we would not know how much to manually reduce our top with to bring the app back into view. This needs to be fixed by Maui team.
Grid.VerticalOptions = Fill
is effectively broken. Even flip flopping it between center
and fill
(in hot+reload) when the bug has occurred does not "fix" the problem. The behavior has changed completely. If your page contains items in keyboard space it will cause the entire application screen to be pushed off at the top by the amount needed else nothing happens. So the only "fix" for now is you got to leave the space at the bottom of the app.
Verified this on VS 17.10.0 Preview 2.0(8.0.7). Repro on Android 14.0-API34, not repro on iOS 17.2 with below Project: ToolbarDemo.zip
Greetings, Might be useful to mention that XAML live preview still believes that the UI components are positioned the same way as they were before keyboard's appearence.
P.S. Any chances this bug will be fixed? After confronting it I really regret that I've chosen MAUI for my project.
Description
I have created a simple .NET MAUI sample, and in the
ContentPage
I have added aStackLayout
with threeBoxView
(s) and anEntry
control as its child. Deployed in Android, when clicking theEntry
the keyboard pops up and the UI (Home bar along with the elements) moved upward. This scenario worked fine in iOS platform only the elements in theContentPage
moved upward.Steps to Reproduce
BoxView
(s) and anEntry
control as its child.Entry
control.https://github.com/dotnet/maui/assets/102582824/ffde53ca-e5e3-4d73-9fff-03b000a5aa19
The issue reproducible sample is attached below. ToolbarDemo.zip
Link to public reproduction project repository
No response
Version with bug
Unknown/Other
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
Android
Affected platform versions
No response
Did you find any workaround?
No
Relevant log output
No response