[regression/8.0.3] Keyboard regression bugs #19214
Comments
|
Hi @williambuchanan2. Thanks for bringing this up. This was something that was considered earlier when I was working on iOS keyboard scrolling. The decision at the time was to keep the behavior the same as what was observed in Android. Do you happen to know if the android behavior is different than what you see here? |
|
I was able to do a basic reproduction on my end and saw this same behavior on iOS and Android. Maybe this is something we need to discuss more on our end. In the meantime, on iOS and Android, you can add |
The behaviour is absolutely different to Android, and also different from when you use a native iOS app. From what I can see there have never been any major issues with the keyboard in Android, but iOS has never been right, and is still not right. You can't even access half the screen when the keyboard is showing. How can there be any question as to whether that is valid behaviour? It is a critical bug and should have been fixed a long time ago, and there are other issues as well. Here are the iOS issues I see with the keyboard:
All the above is different to the behaviour on Android. If you can just get it to behave exactly like Android does then there won't be any problems. |
I think this is part of the problem - you are doing basic reproductions. We are trying to get real apps live and keep running into these problems. It is easy to knock up a quick demo and assume it is ok but when you start using it for real you run into problems. I am happy to do a screen share or discuss more if you want to see these issues in a real app. |
|
Here is a screenshot of Android. As you can see I was able to scroll the screen all the way even with the keyboard showing:
|
This is a band aid on the problem, and not everybody realises what the Next button is for - most people expect to be able to scroll the entire screen. |
|
Just so we are on the same page - here is the same screen in iOS. Notice that as soon as the KB appears I can no longer scroll to the bottom. However, also notice that once I do get to the bottom it then seems to remain able to scroll to that part of the screen, so the problem is with the initial ability to access the bottom of the screen. |
|
Here is another video showing the problem I described earlier where I have an editor on the bottom of the screen. Notice that once the keyboard shows, the top of the screen scrolls out of view, and also I can't access the bottom of the screen. So in this case nothing scrolls which means I lose the top and bottom of the screen. |
|
Here is the exact same code running on an Android device. Behaviour is exactly how I would expect it to be. |
|
And for completeness, here is a video showing the first screen working in Android. Again - exactly the same code working exactly how I expect it to work: |
|
Let me know if you need anything else to help you understand the scale and gravity of this problem... |
samhouts
added
the
potential-regression
|
I have added another reproducable example in the reproduction project. Once you run it, tap "Bottom Keyboard" - note it will take around 10 seconds to fill the screen. Notice the 2 problems:
Although in this app I can get the top of the editor to appear, I can't in my real app - it is completely hidden behind the keyboard all the time. However I think this demonstrates the problem. This is a complete show stopper for me at the moment. At least in .NET 7 I had the IQ.DrasticActions nuget to reduce this problem - I don't have any workarounds to make it work in .NET 8. 
|
samhouts
changed the title
For 1 above, this is interesting. I have a similar code sample as the one you have for your NewPage9.xaml but the scrolling behavior is different on Android. This is one that we will need to inspect more and look into adding into iOS. For 2 above, this seems to be fixed when running your sample on my end with the changes from this PR: #17670 For 3 above, as mentioned above, you should be able to see the bottom editor now. As for the top of the screen moving, this is a fundamental difference between Android and Apple. There is an issue here with specs on how we can better help our users with this exact issue: #11979 |
I pulled your repo and am not able to get this page to fully work. There is some issue with the RestSharp dependency and the app crashes when trying to load in the data. I am however able to get the bottom editor into view after using the new changes in the PR here. While I agree that simpler repros do not always hit the edge cases that full apps will, it does make it easier for us to identify where the problems are and help us get the fixes back out quicker. Does your example here depend on the data getting loaded in after or do you see the same behavior when the Collectionview is initially filled with data? |
|
@tj-devel709 thanks for the update. I have spent the week trying to find a workaround. The closest I have is setting the height of the grid by binding to a value in the VM, and reducing that value when the keyboard shows. When I do this, the star sized area reduces to compensate. The problem I have with #3 above - and this is very relevant to your findings - is that the first time I tap in the editor, the KB shows and it covers the editor and I can't scroll to it. If I press Done on the KB and then tap the editor again everything works fine and continues to work fine. So it looks like there is different behaviour the first time you tap into an editor, compared to subsequent times. This has caught me out before because I thought I had cracked the problem several times, but then discover that on reloading the app it doesn't work on the first tap. |
Apologies - I will look into that problem. The data it loads is largely irrelevant - you just need any content to be loaded into the collection view so that it fills the screen. I will try and rework it to load a local dataset, but you could as easily just replace it with a list of random items I guess. |
|
@tj-devel709 I have just uploaded a fix for that 'Bottom Keyboard' screen. Something that is interesting is that the behaviour seems to vary as you play with it. Most of the time you can see 3/4 of the editor but on occasion it is completely hidden. Either way, you can see that you lose access to half the screen completely with no way to scroll to the bits which go off screen. |
|
Thanks a bunch for updating the code! I also ran into some layout behavior on my side that was causing things to behave differently the first time. I definitely see and agree the top of page thing really affects apps like this and will pass this sentiment up again! Below is how the bottom button is working now for me on a fresh build of the app with the PR changes: BottomKeyboardWithScrollingChanges.mov |
|
@tj-devel709 glad you got it working. In this example, the biggest issue for me is the editor not being in view. I don't know why yet but in my live app I just can't get it to appear - the KB always completely hides it, which is strange because the XAML is the same (in fact I copied it directly into this repro app). Not sure if you noticed as well but the more you play with it the more random the behaviour becomes. It is quite hard to make it happen but sometimes when you scroll up and down the top will eventually jump down into view and then you lose the bottom, or vice versa. It looks like there is something that just triggers it to push the entire screen up or down. |
I did some more digging here as for the number 1 above, and it turns out in this repo, you have set the |
You do not have these changes, right? #17670 (also as a side note, this PR is not landed yet so these changes are not yet available but will hopefully be in soon!) |
No I don't have those changes. My app is live so I am just using the live versions of Maui. |
|
Thought I would just throw another one into the mix. In this screen I have a wizard setup with a 'Next' button on the bottom of the screen. On screens where I show the numeric keypad I can't get past. There is literally no way to proceed because I can't hide the keyboard, and scrolling doesn't help because the button is stuck to the bottom of the screen. Again this doesn't happen in Android because the bottom of the screen moves up. 
|
|
Yes we have this problem as well. The keyboard is overlapping key fields and buttons preventing users from moving forward through a form. On a popup (community toolkit) the keyboard pushed the popup content out of the popup itself if that makes sense. The workaround for that is to disable keyboard autoscrolling. The keyboard is really causing us problems with our users I have already had to perform workarounds for this issue multiple times (all of which no longer work), we need a permanent solution. |
|
Same issue here, the keyboard covers the entry when it's put inside a @tj-devel709 if you need a simple repro, you can draw the main page like this. <?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
x:Class="KeyboardOniOS.MainPage">
<Grid
RowDefinitions="50,*">
<ContentView
Grid.Row="0"
BackgroundColor="Blue" />
<ContentView
BackgroundColor="Yellow"
Grid.Row="1">
<VerticalStackLayout
VerticalOptions="End">
<Label
Text="Hello" />
<Entry />
</VerticalStackLayout>
</ContentView>
</Grid>
</ContentPage>Tested on simulator iPhone 15, iOS 17.2. If you need a real repro, please tell me so I can link you the repo. Simulator.Screen.Recording.-.iPhone.15.-.2024-01-22.at.14.30.22.mp4Unfortunately, I have some cases where this bug is not even deterministic... sometimes it covers the |
|
@riccardominato I think the difference appears when the Keyboard Height changes. In your example you can see the suggestions above the keyboard, which increase the Height. If you turn those off, it probably works. |
|
Did anybody find a workaround for problem number 1? We are also facing that issue. |
Just add a fixed height empty border to the bottom of the page. Crude but works. I believe this problem is being worked on, but it seems like fixes can take months to get live. |
This is working great for single line fields (Entry) but not for multiline text boxes (Editor). In multiline textboxes only the first line is visible. But at least the user can scroll up the text field manually with this workaround... |
Something else I did to fix that was bind the height of the view to an observable property. I then listen for the keyboard show and hide events - when it shows I reduce the height of the view and when it hides I reset the size. It works but the whole thing is a complete pain, and it has some glitches that I wasn't able to completely overcome. It's getting me through until a proper fix is released. |
|
I am facing the same issue after upgrading to .NET 8, till .NET 6 it was working fine for me |
|
Also not working for me in 8.0.7. |
|
@tj-devel709 do you have any insight on when this will be fixed? |
|
Hi, this is also causing me tremendous issues, especially adding SwiftKey keyboard from Microsoft on top of the other issues, as it takes more of the screen size. I have tried many work arounds as well, and used countless of hours to find work arounds. Please keep us updated on progress, and share if you have any workarounds to the issues. |
|
It looks like #20562 fixes the access of the lower part of the UI when the keyboard is open (so point 1 & 2 of original issue). I will try it later today and come back with the results. A bit weird this PR was nog mentioned here. EDIT: (the next is based on a quick view on the main branch with the sample project on a simulator) |
@andyzukunft Then you need to have some method to dismiss the keyboard e.g by adding HideSoftInputOnTapped="True" to the page which displays your component. Or in your subclass of the MauiTextView you can also override the KeyboardDismissMode to let it be interactive. So hopefully the #29562 pull request fixes the issue. I also struggle with the layout jumping all over the place when I try to find a workaround for this issue. What I have tried to to is adding code like this, this works intermittently, and sometimes I get a blank space on the top of the page and sometimes it is not translated enough. Thickness chatGridMargin;
void ChatEditor_Focused(System.Object sender, Microsoft.Maui.Controls.FocusEventArgs e)
{
if (DeviceInfo.Platform == DevicePlatform.iOS)
{
chatGridMargin = ChatMainGrid.Margin;
if(DeviceInfo.Idiom == DeviceIdiom.Phone) {
//iphoneX and above
if (Height > 800)
{
if (Height - ChatMainGrid.Y - ChatMainGrid.Height < 333)
{
ChatMainGrid.Margin = new Thickness(
chatGridMargin.Left,
chatGridMargin.Top,
chatGridMargin.Right,
526);
}
}
//lower screen size of iOS
else
{
if (Height - ChatMainGrid.Y - ChatMainGrid.Height < 258)
{
ChatMainGrid.Margin = new Thickness(
chatGridMargin.Left,
chatGridMargin.Top,
chatGridMargin.Right,
215);
}
}
}
else if(DeviceInfo.Idiom == DeviceIdiom.Tablet)
{
ChatMainGrid.Margin = new Thickness(
chatGridMargin.Left,
chatGridMargin.Top,
chatGridMargin.Right,
426);
}
}
}
void ChatEditor_Unfocused(System.Object sender, Microsoft.Maui.Controls.FocusEventArgs e)
{
if (DeviceInfo.Platform == DevicePlatform.iOS)
{
ChatMainGrid.Margin = chatGridMargin;
}
} |
I'm facing the same problem as in topic 1. The entire list is pushed up, leaving the items outside the visible area, and you can't view it until you close the keyboard. I'm using the latest version of Maui 8.0.10 |
That's disappointing. I had just been told (#21168 (comment)) that it was fixed. Too good to be true. |
|
Any update on this? We cannot release apps to prod without basic problems like this fixed. We need an ETA or solid workaround. |
|
From what I have been told the PR for this has now been released. I'm confused though because literally nothing has changed with the keyboard. It's just the same messed up as it has always been. |
|
Hi all, just wanted to let you know I am looking more into this! |
|
The #2 issue from the first post here should be fixed and #3 is being discussed for the future. This long thread with different issues makes it harder to be sure the issues are getting full attention / we have proper reproduction so I'll close this thread after issue #1 is fixed, and we can start new issues with any other ios keyboard scrolling related things. This way, we can ensure the issues are getting proper attention, we can add them to the proper project boards, and we can try to get quicker fixes out to all of you. Thank you! |
|
Unfortunately it seems that #3 is the critical part of the problem, and without a fix for that, from what I can see, the other fixes don't seem to have solved much. The end result is that we still lose access to half the page when the keyboard is showing. |
|
Didn't this all work in Xamarin? Plus doesn't the native keyboard on the various platforms handle this stuff by default (i.e. moving the content up so it is accessible)? It seems strange that MAUI is somehow breaking this, what's the deal? |
To solve problem #1 in xamarin I had to create a CustomPageRenderer to get around the problem of pushing the list up. I tried using the same one on Maui, but was unsuccessful. |
|
Good to know Xamarin wasn't perfect. Anecdotally, I just don't recall having end users complain so much about the keyboard. A good chunk of our bugs were related to keyboards overlapping screens and users getting "trapped" as buttons weren't tappable due to being scrolled offscreen. We've had to enable that "tap to close keyboard" attribute on almost every page to give users an escape hatch, but the UI looks naff when someone taps on an entry and has to key stuff in blind. With Xamarin we didn't give it a second thought - we threw it all on the page and it just seemed to work like any other native app. |
I believe this has been an unresolved problem from the Xamarin years. Hard to believe it's been broken all those years. You would think the default behaviour on the platform would kick in but doesn't seem to be the case. The thing is it works perfectly on Android - all they have to do is make it work exactly the same way as Android but for some reason that doesn't seem to be happening. |
|
I recently spent too much time coming up with a workaround to fix keyboard overlapping in my app. In my case, we show a PageSheet modal with a large multiline Editor with a toolbar above it. I created a More specifically, that
namespace Project.Behaviors;
public partial class SoftKbResizeBehavior : Behavior<View>
{
View View { get; set; }
protected override void OnAttachedTo(View bindable)
{
base.OnAttachedTo(bindable);
View = bindable;
View.Loaded += View_Loaded;
View.Unloaded += View_Unloaded;
}
private void View_Loaded(object sender, EventArgs e)
{
Attach();
}
private void View_Unloaded(object sender, EventArgs e)
{
View.Loaded -= View_Loaded;
View.Unloaded -= View_Unloaded;
Detach();
}
partial void Attach();
partial void Detach();
}
// Adapted from https://developer.apple.com/documentation/uikit/uiresponder/1621578-keyboardframeenduserinfokey
using CoreGraphics;
using Foundation;
using Microsoft.Maui.Handlers;
using UIKit;
namespace Project.Behaviors;
public partial class SoftKbResizeBehavior
{
UIView UIView { get; set; }
NSObject ObserveWillChangeFrameToken { get; set; }
partial void Attach()
{
UIView = (View.Handler as ViewHandler).PlatformView;
ObserveWillChangeFrameToken = UIKeyboard.Notifications.ObserveWillChangeFrame(OnKeyboardWillChangeFrame);
}
partial void Detach()
{
ObserveWillChangeFrameToken.Dispose();
}
void OnKeyboardWillChangeFrame(object sender, UIKeyboardEventArgs e)
{
var intersection = CGRect.Intersect(UIView.Frame, e.FrameEnd);
if (intersection.IsEmpty)
{
View.HeightRequest = -1;
View.VerticalOptions = LayoutOptions.Fill;
}
else
{
var uiViewFrameInWindowCoordinateSpace = UIView.CoordinateSpace.ConvertRectToCoordinateSpace(
UIView.Frame, UIView.Window.CoordinateSpace);
var viewMaxY = uiViewFrameInWindowCoordinateSpace.GetMaxY();
var intMinY = intersection.GetMinY();
var offset = viewMaxY - intMinY;
View.HeightRequest = View.Height - offset;
View.VerticalOptions = LayoutOptions.Start;
}
}
}Example of how I use it: <?xml version="1.0" encoding="utf-8" ?>
<ContentView>
<ContentView.Behaviors>
<behaviors:SoftKbResizeBehavior />
</ContentView.Behaviors>
<Border>
<StackLayout Orientation="Vertical">
<Grid>
<!-- Toolbar items here -->
</Grid>
<AbsoluteLayout VerticalOptions="FillAndExpand">
<Editor
AbsoluteLayout.LayoutFlags="All"
AbsoluteLayout.LayoutBounds="0,0,1,1" />
<!-- Views to float over the Editor -->
</AbsoluteLayout>
</StackLayout>
</Border>
</ContentView>
Notes:
|
|
This problem also occurs in Xamarin.Forms, I solved it by adapting the following code XF issue and it still works today. For xamarin it is a PageRenderer, but for Maui I believe it should be a CustomPageController and CustomPageHandler, but I couldn't make it work. If anyone can manage it, it would be a great temporary fix for the problem. |
and others
Description
Exactly as documented here:
#14173 (comment)
This issue was resolved in June last year and is now back in .NET 8.
Here are the iOS issues I see with the keyboard:
All the above is different to the behaviour on Android, and native iOS apps. If you can just get it to behave exactly like Android does then there won't be any problems.
Steps to Reproduce
Open reproduction app.
Tap the "Keyboard Problem" button.
Tap one of the top fields - soft keyboard shows.
Now try to scroll down to get to one of the bottom fields on the form
Notice bottom of form is not accessible when soft keyboard is showing.
Link to public reproduction project repository
https://github.com/williambuchanan2/MauiNavigation
Version with bug
8.0.3
Is this a regression from previous behavior?
Yes, this used to work in .NET MAUI
Last version that worked well
7.0.101
Affected platforms
iOS
Affected platform versions
No response
Did you find any workaround?
No
Relevant log output
No response
The text was updated successfully, but these errors were encountered: