In bug 107491 I added new code that would: - prefer error strings defined by PSM - fall back to error strings provided by NSS My patch to fall back to the NSS error strings was incomplete. I had introduced a new nsserrors.properties file, but I continued to look for string IDs in the existing file. While a simple fix would be to move all the NSS error strings to the existing properties file, I explicitly don't want to do that. I would like to have nsserrors.properties as a separate file so it can easily get dynamically updated (we don't do that yet, but we should in the future). This bug didn't get noticed earlier, because nearly all NSS error codes had overrides defined in PSM. When we recently reviewed bug 355643 we removed PSM's overrides for most errors, and today I finally noticed we provide no error explanation... I'm attaching a patch that introduces a new string bundle, and change PSM to do the lookup in the correct bundle file...

Comment on attachment 269852 [details] [diff] [review] Patch v1 r+ with comments. 1) when collecting the id strings, we have a test to see if theBundle != NULL. This is good, but in the previus if, we only checked to see if the id_str is not null. This means that if the mPIPNSSBundle is null we don't fall back to the NSSBundle for those override messages. 2) NSSBundleFormatStringFromName () does not seem to be called from anywhere. If it's global, it might make more sense to use PIPNSSBundleFormatStringFromName and have it call NSSBundleFormatSTringFromName if it's not an override. (Then again I could be completely misunderstanding how this function is supposed to be used, in which case ignore the comment). bob

(In reply to comment #2) > 2) NSSBundleFormatStringFromName () does not seem to be called from anywhere. Yes, I added this to be complete and have parity on functions available for both bundle. > If it's global, It's only accessible from within the PSM module. > it might make more sense to use > PIPNSSBundleFormatStringFromName and have it call NSSBundleFormatSTringFromName > if it's not an override. Well, these functions purely operate on the string identifier. They have no knowledge which bundle contains which strings, we have to rely on the context for that decision, which is made by the caller of either function.

fixed