A raíz del trabajo que estamos haciendo para sacar la próxima versión de Synctur (que por cierto verá la luz en muy poco tiempo) hemos encontrado un curioso BUG en el comportamiento de los TextField de entrada de tipo password. El problema lo hemos encontrado compilando contra AIR 3.1 desde Flash Professional CS5.5 y no hemos sido los primeros en localizar el problema como demuestra esta entrada en los propios foros de Adobe, pero no se ha dado respuesta (tampoco está dado de alta en la base de datos de bugs de adobe) y al menos podemos aportar algo de luz. Estamos casi convencidos que en versiones previas de AIR esto no ocurría (no podemos asegurarlo al 100%, pero este bug ha salido justo al compilar con 3.1)

Otro dato curioso es que es un problema relacionado exclusivamente con iOS, ya que se da tanto en un iPad con iOS 4.3 como en un iPhone con iOS 5.1, y por el contrario, el mismo código funciona correctamente en terminales android, tanto tablets como dispositivos.

El bug es bastante sencillo de reproducir, creamos un campo de texto de entrada de tipo «password» y le asignamos una cuenta no convencional, embebiéndola (incrustando los caracteres). Ha de ser tipo password, ya que con textos de entrada convencionales funciona correctamente.

Al tomar el foco y comenzar a escribir, aparecerá el mecanismo de enmascarado mediante «*», y con la mecánica clásica en iOS de mostrar solamente la última letra introducida. Hasta aquí vamos bien…

El problema surge cuando salimos del campo de texto dando el foco a cualquier otro elemento. El texto enmascarado con «*» desaparece… pero solo «visualmente», porque si volvemos a dar el foco a dicho campo, podréis ver que retoma su contenido y funciona nuevamente con normalidad… pero en cuanto pierde el foco desaparece el texto.

No tenemos constancia de que se haya solucionado en AIR 3.2 o 3.3 ya que no hay feedback desde Adobe sobre el bug en cuestión (aunque estas pruebas si las podemos realizar, y actualizaremos esta entrada con los resultados).

Mientras tanto hay un pequeño y sencillo workaround que podemos emplear para salir del paso (evidentemente más allá de programar un TextField con comportamiento similar al de tipo password por nuestra cuenta) y que consiste en usar fuentes del sistema en el campo de texto. Cuando empleamos éstas (por ejemplo _sans) el bug deja de producirse.

Otra prueba que tenemos pendiente de realizar, y que pensamos que solventará el problema también es usar StageText (disponible desde AIR 3) para acceder a funcionalidades de texto nativas y concretamente el wrapper creado por Christian Cantrell: Native Text.