Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[iOS] Keyboard covers the entry #4792

Closed
Tracked by #11703
HobDev opened this issue Feb 19, 2022 · 78 comments · Fixed by #13499
Closed
Tracked by #11703

[iOS] Keyboard covers the entry #4792

HobDev opened this issue Feb 19, 2022 · 78 comments · Fixed by #13499
Assignees
Labels
area-controls-entry Entry fixed-in-8.0.0-preview.3.8149 Look for this fix in 8.0.0-preview.3.8149! p/0 Work that we can't release without partner/cat 😻 this is an issue that impacts one of our partners or a customer our advisory team is engaged with platform/iOS 🍎 s/verified Verified / Reproducible Issue ready for Engineering Triage t/bug Something isn't working

Comments

@HobDev
Copy link

HobDev commented Feb 19, 2022

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

@HobDev HobDev added the t/bug Something isn't working label Feb 19, 2022
@HobDev HobDev changed the title [iOS] Keyboard coves the entry [iOS] Keyboard covers the entry Feb 19, 2022
@borisoprit
Copy link

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

@jsuarezruiz jsuarezruiz added high It doesn't work at all, crashes or has a big impact. area-controls-entry Entry platform/iOS 🍎 labels Feb 21, 2022
@Eilon Eilon added the legacy-area-controls Label, Button, CheckBox, Slider, Stepper, Switch, Picker, Entry, Editor label Feb 22, 2022
@VincentBu
Copy link

verified on IOS:
image

image

it works properly on Android:
image

@VincentBu VincentBu added the s/verified Verified / Reproducible Issue ready for Engineering Triage label Mar 2, 2022
@Redth Redth added this to the 6.0.300 milestone Mar 22, 2022
@Redth Redth removed the high It doesn't work at all, crashes or has a big impact. label Mar 23, 2022
@samhouts samhouts modified the milestones: 6.0.300, 6.0.300-servicing Apr 20, 2022
@HobDev

This comment was marked as off-topic.

@svaldetero
Copy link

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

@xwang-888
Copy link

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

@HobDev
Copy link
Author

HobDev commented Aug 4, 2022

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

@xwang-888
Copy link

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

Still happening as of August 23, 2022

@xwang-888
Copy link

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

@jsuarezruiz This issue needs to be resolved asap

@xwang-888
Copy link

@jsuarezruiz此问题需要尽快解决

It seems that no one cares about this problem.

@Vpatel541
Copy link

@geraldmrv

@williambuchanan2
Copy link

williambuchanan2 commented Feb 15, 2023

Just tried on a Pixel 2 emulator running Android 11 and have the same problem.

@riccardominato
Copy link

I can't get to Contact 2 unless I minimise the keyboard.

That's completely another story. I wouldn't say that's a problem either. This issue is about the keyboard covering a focused Entry. Look at #4792 (comment). Your focused entry is well visible.

It is inevitable to hide some Entries when there are so many of them under the focused one and the keyboard shows up.

If your problem concerns usability because you don't want people to dismiss keyboard every time, you can use ReturnType="Next".

<Entry Text="{Binding Contact2Name}" ReturnType="Next" />

This way, when the user taps the "Enter" button the following entry is focused without the need to dismiss the keyboard.

AFAIK this currently works only on Android, but there is already a merged PR #11914 for iOS, so I think it will be available soon.

@williambuchanan2
Copy link

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.

image

@riccardominato
Copy link

riccardominato commented Feb 15, 2023

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
Copy link
Contributor

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

williambuchanan2 commented Feb 16, 2023

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

@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

@PureWeen PureWeen added p/1 Work that is important, and has been scheduled for release in this or an upcoming sprint and removed p/0 Work that we can't release without labels Feb 16, 2023
@williambuchanan2
Copy link

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

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

@samhouts samhouts added p/0 Work that we can't release without and removed p/1 Work that is important, and has been scheduled for release in this or an upcoming sprint labels Feb 16, 2023
@riccardominato
Copy link

riccardominato commented Feb 17, 2023

@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
Copy link

Thanks @riccardominato - will give that a go.

@massijay
Copy link

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

https://github.com/massijay/iOSMauiScrollUpOnKeyboardShow

@PureWeen
Copy link
Member

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();

@samhouts samhouts added the fixed-in-8.0.0-preview.3.8149 Look for this fix in 8.0.0-preview.3.8149! label Apr 12, 2023
@NPadrutt
Copy link

@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
Copy link
Member

@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
Copy link

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

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
Copy link
Member

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

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

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

@ghost ghost locked as resolved and limited conversation to collaborators May 17, 2023
@Eilon Eilon removed the legacy-area-controls Label, Button, CheckBox, Slider, Stepper, Switch, Picker, Entry, Editor label May 10, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-controls-entry Entry fixed-in-8.0.0-preview.3.8149 Look for this fix in 8.0.0-preview.3.8149! p/0 Work that we can't release without partner/cat 😻 this is an issue that impacts one of our partners or a customer our advisory team is engaged with platform/iOS 🍎 s/verified Verified / Reproducible Issue ready for Engineering Triage t/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.