[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. 
|
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. |
|
Any update on this? Seems to still be broken from what I can see. |
Thanks @tschbc that workaround was a huge help. I applied this behavior to all
It's not perfect but seems to work well enough for now. ETA: Oh, I forgot, I also had to change some ETA (Again 😅): I should probably mention that it appears the reason our editor may have required a little extra elbow grease is because it expands its height when it is focused (so it's the same height as an Entry until its focused). We tried a variety of approaches to get the size thing to work as close to our earlier XF version as best we could but none of them worked perfectly out-of-box. We went with using the common Visual States to adjust the height on focus in the end. |
PureWeen
added
the
p/1
|
@TheXenocide Could you show us some code of your workaround? Would be very helpful, as I am struggling with the |
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: