In some Entry fields the keyboard is closing on every key stroke. This problem was introduced since Xamarin Forms 3.0. So in 2.5 this problem didn't occur.
The problem only occurs when the controls are in a TableView.
This problem only occurs in iOS, not Android (afaik). I've tested in iOS 12.0, 12.1.
Use the attached test project.
On an iPhone SE screen size, the problem occurs in entry field number 10 and 11, at least in my test scenario. If you use an other iPhone with a larger screen size, like XR, the problem occurs in other Entry controls, lower in the screen (> control no. 11).
Keep the keyboard open.
Keyboard closed on every key stroke.
Version with issue:
From XF 3.0, also in latests pre-release (3.4).
Last known good version:
Xamarin Forms 2.5.
IDE:
Platform Target Frameworks:
Android Support Library Version:
Addition: The problem only occurs, when HasUnevenRows is set to true on the TableView.
Hm. Unable to reproduce on 3.4.0. Please re-open if you can reproduce on the latest nightly.
@kingces95 I've just tested again with the same test project using the latest stable and pre-release version of XF. In both cases I can reproduce it.
I'm testing on a Mac with the latest versions of Xcode and VS. I'm using "iPhone SE 12.1" as the simulator, but I can also reproduce it on a real device (also a iPhone SE). But other iPhone models have the same problem; it's not only SE (of course).
On the iPhone SE I have it on field 10 and 11. Not field 1-9 and from field 12. Field 10 and 11 are fields that aren't visible on the SE screen size, without first scrolling to it.
NB: I can't reopen this issue myself. I don't have the rights.
@pauldipietro Can you please reopen this issue for me? I don't have the rights to do it myself (afaik). Thank you!
Same issue. Entry lost focus on iOS when is inside a ViewCell of table view, from version > 3.
I have tried all release and pre-release from > 3, but there is always the problem.
@kingces95 needs to be reopened
@kingces95 @pauldipietro Can someone please reopen this issue. I can't believe it was closed so easily after one failed reproduce attempt, without first asking for more info. I'm still on XF 2.5 because this is one of a number of bugs still in 3.x.
@john1900s i think we can reopen a new issue if nobody reopens this one.
@pigiax Yes, but that would be a bit messy imho. I don't understand why it should be so hard to reopen an existing one. I do hope that fixing bugs is much more important than introducing new shiny features.
I can reproduce this with 3.4 and it only affects the two fields in question.
@malsama I have found a workaround for the moment. I need to test it deeply, but for the moment seems to work.
You need to create a custom render for iOS:
[assembly: ExportRenderer(typeof(CustomEntry), typeof(CustomEntryRenderer))]
namespace CustomApp.Mobile.iOS
{
public class CustomEntryRenderer : EntryRenderer
{
private bool _isWriting;
protected override void OnElementPropertyChanged(object sender, PropertyChangedEventArgs e)
{
if (!(_isWriting && e.PropertyName == "CursorPosition"))
base.OnElementPropertyChanged(sender, e);
if (e.PropertyName == "Text")
_isWriting = true;
else
_isWriting = false;
}
}
}
Let me know if it's working also for you.
When will this bug be finally solved? I'm still on 2.5 because this bug still exists, which is embarrassing. It's pleasant to work on new shiny features, but can we please give obvious bugs more priority?
@malsama I have found a workaround for the moment. I need to test it deeply, but for the moment seems to work.
You need to create a custom render for iOS:[assembly: ExportRenderer(typeof(CustomEntry), typeof(CustomEntryRenderer))] namespace CustomApp.Mobile.iOS { public class CustomEntryRenderer : EntryRenderer { private bool _isWriting; protected override void OnElementPropertyChanged(object sender, PropertyChangedEventArgs e) { if (!(_isWriting && e.PropertyName == "CursorPosition")) base.OnElementPropertyChanged(sender, e); if (e.PropertyName == "Text") _isWriting = true; else _isWriting = false; } } }
Let me know if it's working also for you.
Thanks, but I will not use more custom renderers anymore. XF should make life simple, while adding custom renderers all over the place, would make me think why I hadn't just started native projects instead of XF ....
@malsama I have found a workaround for the moment. I need to test it deeply, but for the moment seems to work.
You need to create a custom render for iOS:[assembly: ExportRenderer(typeof(CustomEntry), typeof(CustomEntryRenderer))] namespace CustomApp.Mobile.iOS { public class CustomEntryRenderer : EntryRenderer { private bool _isWriting; protected override void OnElementPropertyChanged(object sender, PropertyChangedEventArgs e) { if (!(_isWriting && e.PropertyName == "CursorPosition")) base.OnElementPropertyChanged(sender, e); if (e.PropertyName == "Text") _isWriting = true; else _isWriting = false; } } }
Let me know if it's working also for you.
Thanks for this Workaround!
Following line causes the issue with repeated "Control.BecomeFirstResponder()" calls within "UpdateCursorSelection":
https://github.com/xamarin/Xamarin.Forms/blob/3.5.0/Xamarin.Forms.Platform.iOS/Renderers/EntryRenderer.cs#L379
And it happens not on every stroke in my app: A few times i had to focus / unfocus (any) textfield by myself before it starts to onfocus on every stroke (on any textfield).
This happens to me on Xamarin Forms 4.0.0.497661 too
Sort of related: In the same configuration of Listview/Editor/HasUnEvenRows, Android will move the CursorLocation to 0 when editing for the first time
We have also hit this issue - Only seems to affect iOS 11+, iOS 10 is not affected.
Hit same problem. Rather than worrying about CSS and superfluous XF "features" would it be possible to fix bugs so that basic functions work as expected and XF becomes stable. This goes back to Nov 2018 and XF 3!!
Most helpful comment
@malsama I have found a workaround for the moment. I need to test it deeply, but for the moment seems to work.
You need to create a custom render for iOS:
Let me know if it's working also for you.