I've recently discovered a problem in my app that only seems to occur in iOS 10 where the system keyboard does not display when programmatically triggering a text field to become first responder inside of a completion handler -- specifically the completion handler I get back from a Touch ID attempt.
The crazy part of this issue is, even though the keyboard is not shown, the area on the iPhone where the keyboard normally would be is still responding to touch inputs as if the user is typing on the keyboard!
After doing a lot of investigation and debugging into the issue, I stumbled across the fact that the hidden property is set to YES on the private UIRemoteKeyboardWindow that gets created after becomeFirstResponder is invoked on the text field. In other situations where I bring up the keyboard, the value of that hidden property is set to NO.
Has anybody else run into this problem in iOS 10? If so, anybody found a solution to this? I tried manually setting the hidden value to YES on the window instance but that had no effect on it. I'm pretty much grasping at straws at this point.
Attachments:
Here's the output of the windows from the UIApplication instance when the text field becomes first responder outside of the Touch ID completion handler (pay close attention to UIRemoteKeyboardWindow):
And when the UITextField becomes the first responder inside the Touch ID handler...
First Update
So I did not consider the becomeFirstResponder being done on the main thread before that some have pointed out, but unfortunately, it did not resolve the issue -- however, I did make some additional discoveries. The hidden window issue seems to stem from outputting the details of the UIApplication instance's windows immediately after issuing the becomeFirstResponder action. After doing that, I set a breakpoint on the UITextField editing callback and proceed to interact with the keyboard (that is invisible) -- and when I output the window details, it doesn't seem like the hidden property is ever set to YES (which can possibly rule out that property being set as the cause of the issue), but I still have an invisible keyboard! I started debugging the view hierarchy and below is a screenshot of what it looks like when I examine the keyboard window:
Hopefully you guys can see what I discovered here which is that the keys are present but there appears to be some white view blocking them from sight. The thing is, I don't even see those white views on my app screen. I just see what normally sits behind the keyboard when it's present.
As a temporary workaround, call becomeFirstResponder after a delay fixed this, however, not happy with the hacky solution.
Looks like the issue occurring for different scenarios too - keyboard could be invisible even if you are selecting the textField manually after cancelling touchId alert.
Related
Okay i have two urtext fields, when i click on one of them, the keyboard shows.
now i have another button so when the user clicks it, i want to hide the keyboard (okay it is a stupid design, but i am just learning).
when the user clicks that button, what i do in code is calling the resignfirstresponder method on both of the ui text fields like this:
self.firstuitextfield.resignFirstResponder()
self.seconduitextfield.resignFirstResponder()
and by some maject the keyboard disappear, my question is why is that?
I just removed the first responder from them, and that means, according to this question, they will not receive the messages first anymore. How can this make the keyboard disappear? and bty who now becomes the first responder?
Nobody is the first responder! That's what's happening! And if they're no responders, then the keyboard hides! Pretty nifty, right? But if you want one line of code to do this, try self.view.endediting(true), instead.
I've had a crash report, it's a real edge case. I launch a pin security view from applicationWillEnterForeground (the feature is optional). However, I have some form sheets which I use in some situations in my app.
So the pin view is added as a subview on window and a keypad is presented.
When the form sheet is showing, it appears on top of the pin view (which is wrong) and an action on the form sheet causes a crash, when showing another keypad.
So I believe I need to dismiss any form sheets if the application resigns / becomes active.
I've looked into sending a notification to the form sheet in applicationWillEnterForeground, however I'll have to firstly determine if a form sheet is visible then add method to dismiss it every form sheet.
This seems a lot of work for an edge case, can anyone suggest an alternative approach?
For completeness here's the error...
The layout constraints still need update after sending -updateConstraints to <_UIKeyboardLayoutAlignmentView: 0x14e59b790; frame = (0 0; 0 0); userInteractionEnabled = NO; layer = >. _UIKeyboardLayoutAlignmentView or one of its superclasses may have overridden -updateConstraints without calling super. Or, something may have dirtied layout constraints in the middle of updating them. Both are programming errors.
I've seen this...
NSInteralInconsistencyException - UIKeyboardLayoutAlignmentView
However, I'd still need to end editing in various form sheets, which I can't access from applicationWillEnterForeground.
OK, after researching the issue I discovered that I needed to observe the application state. On notification then check if various objects are load and if so, resignFirstResponder when the keyboard is shown (aka is editing) (I had a text field in an UIAlertView), dismiss an UIAlertView and then dismiss in the view controller used in dialog.
Shesh... so not as simple as I was hoping.
Although this is an edge case for me, I figured I should fix it.
I also found this which will dissmiss alertviews https://github.com/sdarlington/WSLViewAutoDismiss
Which will save me a lot of hassle in simpler scenarios.
Apparently since iOS4, Apple recommends cancelling UIAlertViews and UIActionSheets when an application becomes active.
I have a UITextField with custom keyboard, basically like a calculator. I would like my keyboard show up by default, so i used [self.topInputTextField becomeFirstResponder]; in viewDidLoad, I think that's very common usage. However, it causes some very weird actions on my textfield.
When i set my textfield as the first responder in viewDidLoad, and every time after i done editing, the text will jump, and when i click another text field and and click the first text field again, the texts in the first text field sometimes shift down and disappear, but sometimes not. I feel it's very hard to describe, so i recorded a GIF image for it.
And the reason, that I am sure [self.topInputTextField becomeFirstResponder]; causing the issue, is when i comment that line of code out, everything back to normal. here is the GIF after i comment out that line:
that's vert strange to me, between 2 GIF file, the only change i did is comment out that line of code. I couldn't find any solution on SE. Any idea would be very appreciated.
Edit:
One more thing is I tried to change font, and font sizes, they all have similar strange behaviors.
*Edit 2:**
here is how i set up my textfield,i didn't do anything fancy
Try calling the keyboard in viewDidAppear, this method gets called after viewDidLoad. I assume it's because you should only call the keyboard on a loaded view that has appeared to the user, so if you call it before the view actually appears it will cause unexpected behaviour.
viewDidLoad is too early for calling this, the UI hasn't worked out which size your screen is, or even which orientation your device is in. It isn't yet a UI really... Try it in willAppearAnimated: ..
How can I set voice over focus on my element (such like UITextView) in iOS 6. Is it possible?
Very simple. Just do this:
UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, textView);
Note that it may not work, depending on where and when you use it. If you're trying to set the focus to a particular element from viewDidLoad, the code probably won't work correctly. This is because VoiceOver makes its own attempt to set the VoiceOver focus on an element initially; if VoiceOver does this before it processes your attempt to set focus, your code will work. But if VoiceOver gets around to setting the initial focused element after it processes your attempt, your code will appear to fail.
A somewhat more reliable way to do this in viewDidLoad is to use performSelector:withObject:withDelay:, to ensure that your call is processed after VoiceOver's initial focus setting.
This is one of those "it was working a while ago" troubleshooting efforts.
I'm working on the document preview view controller, in which is a scroll view, which itself contains subclasses of UIView that represent each document. I'm modeling this pretty closely to how Keynote handles its document preview, except I build my scroll view horizontally and with paging. But the standard user experience is present: Long press on a document icon causes all document icons to start jiggling, nab bar has + button and Edit button, etc.
The issue at hand is that when you tap on the name of a document, I hide all the others, move the one being edited front and center, build a new text edit field, add it as a subview atop the real name label, and set it as first responder; but the
[editNameTextField setClearButtonMode:UITextFieldViewModeWhileEditing];
while correctly showing in the edit field is not taking any action when the user taps on the clear button.
I can't figure out what I may have done to cause this to not work -- it had been!
My first thought was that somehow my instance of this subclass is no longer the delegate for this text edit field. To try and confirm/deny that, I usurped a tap on the image view of the document preview to compare the delegate property to self, and it passes.
if (editNameTextField) {
NSLog(#"editNameTextField is still active");
if ([editNameTextField.delegate isEqual:self]) {
NSLog(#"we're still the delegate for the editNameTextField");
}
}
Editing the text within the edit field works fine. Pressing the Return/Done key correctly sends the delegate message textFieldShouldReturn:
While investigating this I implemented the delegate method textFieldShouldClear: just to write a log message if the method gets called (and return YES of course). It never gets called.
My next thought was that perhaps a subview had covered up the area where the clear button sits. So I implemented textFieldShouldBeginEditing: and used the opportunity to bring my the text field to the front. That didn't change anything either. I set a debugger breakpoint there to play a sound when it was called, and it got called, so I know my text edit field is frontmost.
I have only one troubleshooting strategy remaining: Go backwards through snap shots until it starts working again. Before doing that I thought I'd see if any of the more experienced folks out here have any suggestions of what to try next.
Where are you adding the textfield? As a subview of the scrollView? If you added the textfield and it is out of bounds of its parent view it won't receive any touches.
You can try and not call becomeFirstResponder and see if clicking it will show keyboard. Another possible error might be that the parent view of the UITextField has userInteractionEnabled = NO.
Without seeing more code I'm afraid I can not offer more solutions.