[regression/8.0.3] Keyboard regression bugs

[williambuchanan2]

Description

Exactly as documented here:

https://github.com/dotnet/maui/issues/14173#issue-1638336366

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:

1. Once the keyboard appears, you can't access the lower part of the UI. This means you can't access any fields on the bottom half of the screen while the keyboard is visible.
2. If you tap directly into one of those lower fields before the keyboard is showing, then the keyboard comes up over the top of the field, so you can't see what you are typing.
3. When the keyboard shows, in Android the screen scrolls up from the bottom to make way for the keyboard. However in iOS the whole screen moves upwards, so you also lose the top of the screen. This is happening to me when I have a grid as the main container on the page and I have an editor stuck to the bottom of the page - I end up not being able to see the editor, and I also lose the top of the screen. So to summarise - you lose access to both the top and bottom of the screen.

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

[PureWeen]

@tj-devel709 ?

[tj-devel709]

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?

[tj-devel709]

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 ReturnType="Next" to an entry to allow the user to go through all the entries without needing to lower the soft keyboard.

[williambuchanan2]

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?

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:

1. Once the keyboard shows you can't access the lower part of the UI. This means you can't access any fields on the bottom half of the screen while the keyboard is visible.
2. If you tap directly into one of those lower fields before the keyboard is showing, then the keyboard comes up over the top of the field, so you can't see what you are typing.
3. When the keyboard shows, in Android the screen scrolls up from the bottom to make way for the keyboard. However in iOS the whole screen moves upwards, so you also lose the top of the screen. This is happening to me when I have a grid as the main container on the page and I have an editor stuck to the bottom of the page - I end up not being able to see the editor, and I also lose the top of the screen.

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.

[williambuchanan2]

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 ReturnType="Next" to an entry to allow the user to go through all the entries without needing to lower the soft keyboard.

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.

[williambuchanan2]

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:

[williambuchanan2]

you can add ReturnType="Next" to an entry to allow the user to go through all the entries without needing to lower the soft keyboard.

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.

[williambuchanan2]

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.

https://youtu.be/HwaqXZhGSmk

[williambuchanan2]

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.

https://youtube.com/shorts/1ORLUnOJ97Y?feature=share

[williambuchanan2]

Here is the exact same code running on an Android device. Behaviour is exactly how I would expect it to be.

https://youtube.com/shorts/kBFlSdGukhs?feature=share

[williambuchanan2]

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:

https://youtube.com/shorts/Dh6B4PRu3A8?feature=share

[williambuchanan2]

Let me know if you need anything else to help you understand the scale and gravity of this problem...

[williambuchanan2]

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:

1. Top of page vanishing.
2. Unable to fully access editor at bottom of screen.

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.

[tj-devel709]

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?

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:

1. Once the keyboard shows you can't access the lower part of the UI. This means you can't access any fields on the bottom half of the screen while the keyboard is visible.
2. If you tap directly into one of those lower fields before the keyboard is showing, then the keyboard comes up over the top of the field, so you can't see what you are typing.
3. When the keyboard shows, in Android the screen scrolls up from the bottom to make way for the keyboard. However in iOS the whole screen moves upwards, so you also lose the top of the screen. This is happening to me when I have a grid as the main container on the page and I have an editor stuck to the bottom of the page - I end up not being able to see the editor, and I also lose the top of the screen.

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.

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: https://github.com/dotnet/maui/pull/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: https://github.com/dotnet/maui/issues/11979

[tj-devel709]

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:

1. Top of page vanishing.
2. Unable to fully access editor at bottom of screen.

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.

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?

[williambuchanan2]

@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.

[williambuchanan2]

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?

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.

[williambuchanan2]

@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.

[tj-devel709]

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:

https://github.com/dotnet/maui/assets/50846373/640ac270-3060-4905-a6a6-3d041be29a1d

[williambuchanan2]

@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.

[tj-devel709]

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?

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:

1. Once the keyboard shows you can't access the lower part of the UI. This means you can't access any fields on the bottom half of the screen while the keyboard is visible.
2. If you tap directly into one of those lower fields before the keyboard is showing, then the keyboard comes up over the top of the field, so you can't see what you are typing.
3. When the keyboard shows, in Android the screen scrolls up from the bottom to make way for the keyboard. However in iOS the whole screen moves upwards, so you also lose the top of the screen. This is happening to me when I have a grid as the main container on the page and I have an editor stuck to the bottom of the page - I end up not being able to see the editor, and I also lose the top of the screen.

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.

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 did some more digging here as for the number 1 above, and it turns out in this repo, you have set the On().UseWindowSoftInputModeAdjust(WindowSoftInputModeAdjust.Resize); and that is what allows Android to not only see the top of the screen but also scroll to the bottom when the soft keyboard is up. This is also what I was referring to in number 3 with this spec #11979. (I am also adding this here for myself)

[tj-devel709]

@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.

You do not have these changes, right? https://github.com/dotnet/maui/pull/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!) Without these changes then the editor will probably not be in view. Let me know if I am misunderstanding you. If you are able to get video of the behavior you mention above, please do send it, I am not sure if I follow

[williambuchanan2]

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!) Without these changes then the editor will probably not be in view. Let me know if I am misunderstanding you. If you are able to get video of the behavior you mention above, please do send it, I am not sure if I follow

No I don't have those changes. My app is live so I am just using the live versions of Maui.

[williambuchanan2]

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.

[riccardominato]

Just meant as a workaround, but you can let the user disposing keyboard by tapping out of the entry.

Set HideSoftInputOnTapped to true for ContentPage.

[ghost]

We've added this issue to our backlog, and we will work to address it as time and resources allow. If you have any additional information or questions about this issue, please leave a comment. For additional info about issue management, please read our Triage Process.

[williambuchanan2]

Just meant as a workaround, but you can let the user disposing keyboard by tapping out of the entry.

Set HideSoftInputOnTapped to true for ContentPage.

Thanks - that worked for this problem.

A bit concerned the whole thing has been put into the backlog rather than being fixed...

[andyzukunft]

I can confirm most of the behaviour issues. It seems to vary depending on the iPhone in use. For me most problematic is the keyboard overlapping an input. This only seem to happen with Editor input as only the Editor brings the additional top bar allowing to close the keyboard. As far as I can tell the keyboard on my iPhone SE 3 (which I use because it's display is the smallest we "support") displays correctly when trying to enter data into an Editor, it does not scroll correctly when using a larger screen.

Here an example where an Editor at the bottom of a page is overlapped by the keyboard:

[andyzukunft]

Is there any way to not display the "done"-bar on the iOS keyboard on Editor fields?

[williambuchanan2]

It's worth mentioning this problem while here:

https://github.com/dotnet/maui/issues/17819

Seems to be so many issues related to the iOS keyboard - I hope we can start seeing some improvements.

[NielsKnaap]

In the app we are working on, we are experiencing the same problems with the iOS keyboard. Especially the first one you mentioned where the lower part of the UI isn't accessible by scrolling. In XF this works completely fine.

I just tried it with the nightly build of maui in the hope the PR: https://github.com/dotnet/maui/pull/17670 would change anything to this behaviour. But unfortunately no difference here...

[RobTF]

Yep got this problem too. Keyboard overlaps the input slightly. Currently one of the MAUI issues blocking our release and we have developers internally scrambling for any sort of fix.

[ajay-mundi]

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.

[riccardominato]

Same issue here, the keyboard covers the entry when it's put inside a Grid with a star (*) row definition. Please, give a high priority to keyboard issues, there are some really basic features that can't be achieved because of them.

@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. MAUI version 8.0.6 (SR2).

If you need a real repro, please tell me so I can link you the repo.

https://github.com/dotnet/maui/assets/69031646/863ceac8-2b08-4db1-bf0c-da3f52d15ae1

Unfortunately, I have some cases where this bug is not even deterministic... sometimes it covers the Entry, sometimes it doesn't. It seems to be related to the auto-selection of the word and text suggestions. However, when the bug shows up, the behavior is the same of the sample I provided, so I hope that solving that will solve everything.

[borrmann]

@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. If you have those turned off and switch the keyboard from a regular Keyboard to the Emoji Keyboard you can actively trigger a Height change, the Keyboard will now overlap the Entry. I have posted some snippets here https://github.com/dotnet/maui/issues/10662#issuecomment-1908107436 that can be used as workaround but it depends a little bit on the use case whether its suitable or not.

[ramonB1996]

Did anybody find a workaround for problem number 1?

We are also facing that issue.

[williambuchanan2]

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.

[mahop-net]

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...

[williambuchanan2]

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.

[qualitycodes]

I am facing the same issue after upgrading to .NET 8, till .NET 6 it was working fine for me

[Flais]

Also not working for me in 8.0.7. We are already waiting for month to go on with our app development. This is a productive app still running on xamarin, but we can't go on to MAUI and we are not able to implement new requirements.

[williambuchanan2]

@tj-devel709 do you have any insight on when this will be fixed?

[ReneKrone]

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.

[NielsKnaap]

It looks like https://github.com/dotnet/maui/pull/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) It looks like this PR is a step into the good direction but doesn't fix it completely. Because when you focus on an entry and try to scroll down, there will still be a problem to reach the bottom of the page. Only when you have an entry with ReturnType="Next" and hit next on the iOS keyboard you can scroll all the way down. So it looks like it only recalculates the scroll height after the next button is pressed and you navigate to the next entry (that's outside the current view). I think it would be possible to do this calculation on focus.

[tentom]

Is there any way to not display the "done"-bar on the iOS keyboard on Editor fields?

@andyzukunft You can make a class with a custom handler that inherit from the EditorHandler and override the CreatePlatformView that returns a subclass of MauiTextView.

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;
            }
        }

[davibittencourtome]

1. Once the keyboard shows you can't access the lower part of the UI. This means you can't access any fields on the bottom half of the screen while the keyboard is visible.

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

[williambuchanan2]

1. Once the keyboard shows you can't access the lower part of the UI. This means you can't access any fields on the bottom half of the screen while the keyboard is visible.

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 (https://github.com/dotnet/maui/discussions/21168#discussioncomment-8768061) that it was fixed. Too good to be true.

[RuddyOne]

Any update on this? We cannot release apps to prod without basic problems like this fixed. We need an ETA or solid workaround.

[williambuchanan2]

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.

[tj-devel709]

Hi all, just wanted to let you know I am looking more into this! So the previous fix for issue #1 on this original issue does help with the ContentInsets to reach the bottom of the page, but only when the focused entry/editor is below the keyboard. The code was not doing anything if scrolling was not required and I think that is where some confusion is coming from. I see the comments on wanting this to always work though and am working on a PR to address this. I also found some edge cases with smaller scrollviews that should be improved in this new fix as well.