The Problem:
Setting the passwordMask on a textfield works as expected. Setting the keyboardType also works as expected. When both properties are together, the keyboardType gets ignored.
The Code:
var win = Ti.UI.createWindow({
backgroundColor:'#ccc'
});
var pinTextField = Ti.UI.createTextField({
color:'#333333', value: '',
textAlign:'center',
passwordMask:true,
width:200,
height:100,
keyboardType:Titanium.UI.KEYBOARD_PHONE_PAD,
borderStyle:Ti.UI.INPUT_BORDERSTYLE_ROUNDED,
font:{fontSize:12}
});
win.add(pinTextField);
win.open();
The Ticket:
Associated Helpdesk ticket: *APP-876152*
Associated helpdesk ticekt:APP-382186
For testing, please do two things: 1) Use the sample app.js from above here in this JIRA ticket to test the fix for the specific failcase (password + phone pad). 2) Do the KitchenSink Controls -> TextField tests, particularly "Keyboard" and "The Rest", to be sure I haven't broken anything.
Pull request ready https://github.com/appcelerator/titanium_mobile/pull/459
*NOTE* - Source code of Android's TextView.java shows that they really only consider the field to be password char masked if the input type class is TEXT, and therefore not PHONE. So, technically speaking, the combination of using the phone pad keyboard and password characters is not really supported. The result of this is that some devices -- such as Nexus Ones running 2.3.4 -- will show the clear text when you rotate the device after inputting numbers from the soft phone pad. Meaning: a) Start Portrait; b) enter numbers using the soft phone pad; c) they will appropriately be hidden by the password character; d) rotate the device to landscape; 5) suddenly you will clearly see the numbers you entered -- the password characters aren't used anymore. This problem does *not* occur on all devices. For example, the HTC Desire running Android 2.2 does not exhibit this unfortunate behavior, nor does the T-Mobile G-Slate running Android 3.0.1. But, in our testing, the Nexus Ones running 2.3.3 or 2.3.4 *do* exhibit this problem, as do Nexus S's running 2.3.4 and the HTC Hero running Android 2.1. (There may be several other devices which we have not tested which either do or do not exhibit the problem.) It could be that the devices which do *not* exhibit the problem are using code patched by the manufacturer. For more information: 1) http://stackoverflow.com/questions/2017674/edittext-set-for-password-with-phone-number-input-android/6146252#6146252 2) http://stackoverflow.com/questions/2420181/android-numeric-password-field/4014588#4014588 (See Marcus Wolschon's comment). 3) http://code.google.com/p/android/issues/detail?id=13171&can=1&q=TextView%20landscape%20password&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
Review, merge.
Tested with 1.8.0.v20111006001414 on Hero 2.1 Motorola Xoom 3.2 iPhone 4 4.2.10
Tested with 1.7.4.v20111019130614 on Droid 2.2.2 Hero 2.1 Motorola Xoom 3.2
Standardizing summary and labels.