maui

maui copied to clipboard

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

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

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.

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.

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.

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:

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.

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

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

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

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

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

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.

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

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?

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

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.

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

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

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

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

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.

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.

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.

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.

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

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:

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

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.