[iOS] Keyboard covers the entry

[HobDev]

Developer Notes

• AFAICT the sample attached to this issue wouldn't have worked in XF either. In XF the entries would only scroll into view if you nested your content inside a ScrollView or a ListView

• in XF ListView would scroll into focus but CollectionView would not
  

Approaches here

• Follow the XF approach where it would set the ContentInsets on the UIScrollView in order to adjust the visible area

  • This approach is a bit limited feeling though it's been working on XF so possibly the best approach plus it's in the docs here

• Researching around I don't see a lot of solutions natively that take the approach of scrolling the scrollview. They typically seem to use a layout guide on the root element and then set the height on that layout when the keyboard opens. I've also seen the approach of using Y translation.

  • These two approaches technically match the "AutoResize" and "AutoPan" options we have on android so we could take both of these approaches and make these options apply more xplat opposed to platform specific

Description

The keyboard covers the entry in iOS. Whereas Entry should be above the Keyboard
BugSample.zip

Steps to Reproduce

Run the repro project. Try to enter something in the Entry.

Version with bug

Preview 13 (current)

Last version that worked well

Unknown/Other

Affected platforms

iOS

Affected platform versions

iOS 15

Did you find any workaround?

Workaround 1

https://github.com/PureWeen/ShanedlerSamples
https://www.nuget.org/packages/PureWeen.Maui.FixesAndWorkarounds

builder.ConfigureKeyboardAutoScroll();

Workaround 2

https://github.com/drasticactions/Drastic.IQKeyboardManager

Relevant log output

No response

[borisoprit]

Same problem here in iOS on real divice ( Iphone 6s Plus) Microsoft Visual Studio Community 2022 (64-bit) - Preview
Version 17.2.0 Preview 1.0

[VincentBu]

verified on IOS:

it works properly on Android:

[svaldetero]

I came here from #5121. I opened the sample from there and it still happens on 6.0.301 15.5 simulator.

[xwang-888]

I think this is a very fatal problem, which makes it difficult for me to input text

[HobDev]

It is not possible to publish app to the store until this bug is resolved.

[xwang-888]

This problem is very serious. I don't know which version can be repaired in the future,
I hope the development team can pay attention to it.

[Vpatel541]

Still happening as of August 23, 2022

[xwang-888]

Still happening as of August 23, 2022

I think this problem is very serious, which makes my app unavailable to users. I don't know when this basic problem will be solved

[Vpatel541]

@jsuarezruiz This issue needs to be resolved asap

[xwang-888]

@jsuarezruiz此问题需要尽快解决

It seems that no one cares about this problem.

[Vpatel541]

@geraldmrv

[williambuchanan2]

Hi @riccardominato

I see what you mean about it being a different issue, but it seems this problem with the keyboard getting in the way in general is a long ongoing problem.

I just tried your suggestion but it didn't change anything unfortunately. As you can see from the screen below I am in contact 2 and the UI hasn't moved down.

[riccardominato]

It doesn't make sense to saturate this thread talking about a different issue than the original one.
If you think the app should behave differently you can open another issue or proposal explaining what you expect.

Again, IMO this is the correct behavior. You can't expect to see an undetermined number of Entries under the focused one.

[borrmann]

I agree with @riccardominato and think you could open another issue @williambuchanan2 .
This is not a bug, but maybe something worth to consider for the Maui team. Many apps scroll a focused entry to the centre of the available space instead only into the view, which has the advantage that the user can already see what has to be filled out next.
Maybe this would be better solved with behaviours instead of api changes though, because it is hard to predict in which use cases this is expected behaviour.

[williambuchanan2]

Yeah fair enough - it is a different issue so will raise it separately. To me this is definitely a bug though. You can't expect users to understand that to get to the fields and buttons at the bottom of the screen when the keyboard is visible they have to repeatedly hide the keyboard.

[riccardominato]

@williambuchanan2 I understand your usability issue and that's why I proposed you ReturnType. It wasn't meant to solve your problem the way you would like, but al least the user doesn't have to dismiss the keyboard to reach the next Entry.

Maybe it wasn't clear... Here's a video.

video_next.mov

[williambuchanan2]

Well that was a waste of time. I opened a new bug as discussed (#13380) but then it got instantly closed as a dupe of this bug.

[williambuchanan2]

@williambuchanan2 I understand your usability issue and that's why I proposed you ReturnType. It wasn't meant to solve your problem the way you would like, but al least the user doesn't have to dismiss the keyboard to reach the next Entry.

Maybe it wasn't clear... Here's a video.

Thanks for the update. Yes it goes some way to helping, but my issue is that it only helps the few people who know to tap that button. I'd say the vast majority of people would expect to be able to scroll down.

[riccardominato]

@williambuchanan2 This is probably the closest way to achieve what you're trying to do in Android. Not sure about iOS until they fix this bug.

Put this code in your code-behind. Looking at your code it should be named DomTestPage.xaml.cs.

protected override void OnAppearing()
{
    base.OnAppearing();

    App.Current.On<Microsoft.Maui.Controls.PlatformConfiguration.Android>().UseWindowSoftInputModeAdjust(WindowSoftInputModeAdjust.Resize);
}

protected override void OnDisappearing()
{
    base.OnDisappearing();

    App.Current.On<Microsoft.Maui.Controls.PlatformConfiguration.Android>().UseWindowSoftInputModeAdjust(WindowSoftInputModeAdjust.Pan);
}

Actually I don't like Resize mode too much because it rearranges your components according to the free space available, but if your priority is to let the user scroll, it allows that.

About your issue, maybe you should try to be more specific, including some screenshots or videos of the expected behavior. It wouldn't be bad having a scrollable page without the resizing mess.

[williambuchanan2]

Thanks @riccardominato - will give that a go.

[massijay]

Here is my workaround (inspired also by @npostma idea)

https://github.com/massijay/iOSMauiScrollUpOnKeyboardShow

[PureWeen]

If you want to try this PR out. I've copied @tj-devel709's work to an external nuget here.

https://github.com/PureWeen/ShanedlerSamples
https://www.nuget.org/packages/PureWeen.Maui.FixesAndWorkarounds

builder.ConfigureKeyboardAutoScroll();

[NPadrutt]

@samhouts does that label mean, that the fix is only in the 8.0.0 Preview but was not released for .net7?
I didn't see the fix in the release notes of 7.0.81 Service Release 4 release notes - which would explain why it still doesn't work for me on that release.

[samhouts]

@NPadrutt Yes, that is correct. The team reviewed the fix for servicing to .NET 7, but since the fix requires changes to public API, we're unable to backport it.

@williambuchanan2 I just saw your comment about your issue being closed as a duplicate! If you're able to test with the 8.0 previews, could you please confirm that your issue is or is not resolved by the fix made for this one? If not, I'll get your other issue reopened right away. Sorry for the confusion!

[NPadrutt]

Thanks @samhouts, I appreciate the response.

I have to say, for me it's very unfortunate, that there are several high priority issues (this one here was p0 for the last 2 or 3 months now), that where open for months (this one here for over a year), that finally would have a fix only to have that fix in a version that won't be supported in production for another 7 months or so.

[williambuchanan2]

Thanks @samhouts, I appreciate the response.

I have to say, for me it's very unfortunate, that there are several high priority issues (this one here was p0 for the last 2 or 3 months now), that where open for months (this one here for over a year), that finally would have a fix only to have that fix in a version that won't be supported in production for another 7 months or so.

I agree... I have an app which I have developed for a customer but can't release due to some critical bugs which I have raised but seemingly nodoby has looked at. There are things crashing, unable to navigate between pages, major layout issues, unable to use the camera properly, etc. At the same time I see the maui team working on minor issues in the current sprint. I don't know what to tell the customer... Over 2000 open issues and looks like only a handful of people working on them. Hard to see these issues getting fixed this year at the current rate.

[samhouts]

I understand your frustration. We are working on a variety of issues, some of which are papercuts and some of which are critical, like this one. We're working hard to increase our velocity. You can expect to see more activity in critical issues in the coming weeks.

Please keep reporting issues and commenting on issues that are affecting you. We're listening and we're responding as quickly as we can!!

[williambuchanan2]

I understand your frustration. We are working on a variety of issues, some of which are papercuts and some of which are critical, like this one. We're working hard to increase our velocity. You can expect to see more activity in critical issues in the coming weeks.

Please keep reporting issues and commenting on issues that are affecting you. We're listening and we're responding as quickly as we can!!

Thanks for the update. I'm sure you are all working hard! Even if we can have some kind of workarounds or general idea as to when the problems will be fixed that would be a help, because at the moment it feels like we have been abandoned and you have already moved onto the next thing before you have finished this version.

For me moving to .net 8 isn't an option because we need to have something live way before then, but I should be able to mock something up to see if it has fixed the problem.

[williambuchanan2]

I just tried to do this in .NET 8. Can't build - just getting a bunch of meaningless errors.