[TIMOB-18076] iOS: Keyboard disappears when alert message is fired due to an eventListener on the textfield
GitHub Issue | n/a |
Type | Bug |
Priority | High |
Status | Closed |
Resolution | Won't Fix |
Resolution Date | 2014-12-03T19:25:48.000+0000 |
Affected Version/s | Release 3.5.0 |
Fix Version/s | n/a |
Components | iOS |
Labels | qe-3.5.0 |
Reporter | Visalakshi Chidambaram |
Assignee | Ingo Muschenetz |
Created | 2014-11-24T09:49:38.000+0000 |
Updated | 2017-03-22T17:49:35.000+0000 |
Description
When an eventListener is added to a textfield to show an alert box when the textfield is in focus the keyboard immediately disappears as soon as the alert message appears. This happens regardless of the type of event used in the eventListener. However, using titanium SDK 3.4.1 the alert message appears with the keyboard backgrounded and clicking on the OK button of the alert message allows the user to continue typing which is not possible with the current version.
-->This is a regression.
Steps to reproduce:
1.Run the attached app.js
2. Click on textfield to bring up the softkeyboard
Actual Results:
The keyboard appears and immediately disappears when the alert message appears and hence unable to type anything on to the textfield.
Expected results:
The softkeyboard should show up and alert with no textfield value should also appear. Clicking on the ok button of the alert message should bring the keyboard to focus allowing the user to type.
Attachments
File | Date | Size |
app.js | 2014-11-24T09:49:38.000+0000 | 756 |
This is expected behavior on iOS8. Alerts and OptionDialogs are now presented as modal controllers. So when they come up, the top most window proxy has to resign focus and as a result all editing operations are terminated. So the textField loses focus and the keyboard disappears.
Side effect of Alert Refactor for iOS8
The resolution is won't fix? This is a serious problem. It also happens with popovers and totally hoses the user interface for my app. This needs to be fixed. Reopen this and fix it.
[~dethier1958], please realize the rationale for the "Won't Fix" designation is due to native behavior changes, which in many cases are out of our control to override. If you feel otherwise, please show a test case of your particular situation, and in particular, an instance of a native application with the same behavior you wish us to provide.
Closing ticket as the issue will not fix and with reference to the above comments.