While verifying bug 494899, I noticed some locales like fr or es-es will not allow you to unload a pkcs# device, according to the instructions in bug 494899, comment #18 in the aforementioned bug. This is inconsistent with the behavior in en-US and other locales like de. You are, however, able to "Load" pkcs#11 devices if you follow that part of the instructions. I can see this problem in Fx188.8.131.52, Fx3.0.12pre, Fx3.1b3, and Fx3.5pre, across platforms on at least fr and es-es, but it probably happens with other locales as well. Steps: 1. Install the latest Fx3.5pre (fr locale) 2. Go to the equivalent of Options(Preferences), Advanced, Encryption, and click on Security Devices 3. Select the last item in the list and click on "Unload" 4. Click on OK to confirm that you want to unload the module. Expected: The item disappears from the list. Actual: You get a dialog saying it was not possible to unload the module. Given this behavior has been there since Fx2.x times, this will likely not block, but I will request blocking to get it assessed.
Not blocking 3.5 final, would take a fix for 3.5.x, should fix for .next.
It looks like Device Manager have a problem with non-ASCII characters in the name of PKCS#11 devices. Fr and es-ES both have accented characters in their translation of "Builtin Roots Module", removing those fixes this problem. Using non-ASCII characters in the name of a new module is also problematic. You can add such as module, but the name won't show up in Device Manager and you can't see any of the properties of the module.
It appears that the string being passed in goes through truncation via ToNewCString: http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsCrypto.cpp#2989 I can't find docs for the format expected of the const char *moduleName parameter to SECMOD_AddNewModule but I'm pretty sure we just treats it as a sequence of octets and we could pass a UTF8-encoded string. We should probably just switch the nsPkcs11 code to use UTF8 throughout for module names.
This is a bug, but it's not serious enough to block Firefox 4 release. I'd still take a patch, though.
Comment on attachment 516846 [details] [diff] [review] fix r+ for the conversion to UTF8. All NSS/PKCS #11 calls are defined to be UTF8, so UTF16 values should all be converted. Someone else should verify that the memory usage and xpcom standards are correct. bob
Comment on attachment 516846 [details] [diff] [review] fix Thanks Bob. r=kaie for the remainder of the patch
Makoto Kato, thank you very much for your contribution! https://hg.mozilla.org/integration/mozilla-inbound/rev/d20c2724cfb3