La explicacion del problema se puede encontrar acá
En el presente artículo implementaremos una solución que intenta evitar los problemas planteados en el enlace. Como objetivo adicional, tendremos en mente que la cantidad de código utilizado sea claro y óptimo (Legible y mínimo).
Se dice que es una implementación incorrecta ya que puede inducir a diversos problemas ya comentados mas arriba. Estaria mal si decimos que es una implementación insegura, ya que bajo ningún aspecto podemos hablar de seguridad en este tipo de mecanismos, pero si podemos decir que esta primer implementación rompe la semantica que el browser pueda asignarle al campo password.
Esta implementación básica adolece de los problemas planteados en el enlace
La implementación planteada a continuación agrega un control adicional. Al momento del submit, controla que el campo de password sea type="password" nuevamente.
El código adicional agregado a este segundo ejemplo es el siguiente:
var $submitBtn = $('#form-right--send');
$submitBtn.on('click', function(e) {
$passField.attr('type', 'password');
});
Se captura el evento 'click' en el boton de submit (enviar), y se fuerza que el campo sea siempre del tipo 'password'. La última porción de código es prescindible en un sitio real:
var $form = $('#form-right');
$form.submit(function(e) {
e && e.preventDefault();
console.log($passField.attr('type'));
})
Lo único que hacemos aca es capturar el evento submit, impedir que se realize (ya que no sera procesado para este ejemplo), y mostrar el valor final del atributo 'type' del campo 'password' por la consola de javascript.
La idea y ejemplos de este articulo fueron tomados del siguiente post. En dicho link se explica con detalle los problemas de realizar el manejo incorrecto del campo password y la solución completa.