Implementation of "secret" input type leaves much to be desired

What steps will reproduce the problem?
1. Use "secret" instead of "input" to use JavaRosa's "secret" input type.

What is the expected output? What do you see instead?

Expect entered value to be obfuscated in the form entry field itself, but 
otherwise functional. However, as it stands, the feature is not very 
functional. As you enter the value to begin with, it is not obfuscated at all. 
That's fine. But then if you swipe backwards in the survey, the current entry 
is obfuscated with *'s. That's also fine. But if you swipe forward again, the 
field's internal value gets set to *'s, and the original entry is lost. The 
same happens if you save and the edit the form: the original value is often 
replaced with *'s -- not just in the display, but in the form data itself.

Also, if you refer to a secret field with ${fieldname}, you only get *'s -- so 
you can't even, e.g., check to see if an entered password was correct.

In all, it is hard to see under what circumstances the current implementation 
would be useful. Perhaps that's why it hasn't been implemented in XLSForm.

What you want is for secret values to be obfuscated in the UI, so that you 
cannot see the underlying value that was originally entered. But, you want 
entered values to be saved, maintained, and referable via ${fieldname}.

Perhaps this could be implemented with a "secret" appearance attribute for text 
input boxes. Probably the trickiest thing would be figuring out how to obscure 
the value when viewing the form (e.g., in the go-to-prompt or edit-saved-form 
displays), but not obscure it when referring (e.g., via ${fieldname}).

Please use labels and text to provide additional information.

Original issue reported on code.google.com by chrislro...@gmail.com on 18 Jun 2013 at 11:10

javirosa / opendatakit

Implementation of "secret" input type leaves much to be desired #849