I noticed a very strange behavior. To type an umlaut vowel you have to first type a dead char option + u and then the actual vowel that will be an umlaut, for example option + u and then 'a' will print ä. The same goes for accents, etc just using a different dead char combo.
Normal NSTextField accepts these characters no problem. But NSSecureTextField just drops the dead char and only takes what follows. Instead of 'ä' it will only get 'a' because it dropped option + u. If you have a mac you can actually try this out on any system password field. Instead of any vowel in your password just type it accented or umlaut'ed using corresponding dead char combo. The passwords will match, because dead char was dropped.
Now for my application this is completely unacceptable, because i am dealing with entities with passwords created on Windows and Linux where umlauts do get passed. Since i can't type an umlaut in NSSecureTextField on Mac i can't provide a correct password even if i know it!
The question is did anyone encounter this before? How can this be solved? Googling found a couple of mailing list questions that were left without an answer: http://lists.apple.com/archives/student-dev/2006/Apr/msg00052.html and http://lists.apple.com/archives/cocoa-dev/2008/Oct/msg02369.html
I have submitted this as a bug to apple developer support and although they were able to reproduce it they said they won't fix it. For my application i had to implement my own password field mimicking the behavior of the NSSecureTextField (bullets, carbon secure input mode, etc). So i think this is the only workaround you can get - roll out your own password field.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With