User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sr; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; sr; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) If you enter the name of the profile with Unicode characters, Firefox displays error that he can't create profile. It is pretty trobulesome, as localization profiles default name should be in local language, and it might require Unicode. Reproducible: Always
Can you test this on a nightly build? It may well be fixed by bug 469856
No, and the error message is this: Profile couldn't be created. Probably the chosen folder isn't writable. [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIToolkitProfileService.createProfile]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: chrome://mozapps/content/profile/createProfileWizard.js :: onFinish :: line 233" data: no]
Created attachment 425297 [details] [diff] [review] Patch It might be better in some ways to make the profile name in nsIToolkitProfile a wide string instead of a UTF8String, but I don't think I want to open the migration can of worms...
Assignee: nobody → smontagu
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #425297 - Flags: review?(ted.mielczarek)
Comment on attachment 425297 [details] [diff] [review] Patch I'm not sure I'm actually a peer of this code, but clearly I've reviewed stuff here for bsmedberg before. This change looks fine, but do you think you could write a simple xpcshell test for it? This interface is scriptable, so it should be pretty straightforward. Just testing that nsIToolkitProfileService::createProfile() works as expected with an ASCII profile name, and then with a profile name that can't possibly be in the local charset ought to be enough. r=me with a test :)
Attachment #425297 - Flags: review?(ted.mielczarek) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Shame the test doesn't actually look for a Unicode-safe filesystem first ;-)
(In reply to comment #7) > Shame the test doesn't actually look for a Unicode-safe filesystem first ;-) I don't understand this comment.
You need to log in before you can comment on or make changes to this bug.