ENVIRONMENT =========== Windows 2000 Probably, this will reproduce on Windows9x/Mac. REPRO STEP ========== 1. Create JPN username profile by [Computer Management] applet of Control Panel 2. Relogon as 1. user 3. Run Mozilla 4. Create mail account. 5. Select [Task] - [Mail] 6. Select [Edit] - [Mail/News Account Settings] 7. Select [Server] item of left panel RESULT ====== See attached JPG.

Marina or Xianglan, please test and confirm if reproducible.

Confirmed the bug. I can reproduce it on my WinNT4.0-J with 2001-01-29-08-mtrunk build.

This problem also can be reproduced by login to the machine using an ASCII username but creating a mozilla profile in Japanese.

*** Bug 68884 has been marked as a duplicate of this bug. ***

*** Bug 68884 has been marked as a duplicate of this bug. ***

Changed the component to i18n.

Adding nsbeta1 keyword, and cc: jenm. This looks like something we want to get fixed for beta 1. Racham - Please assign priority to P2, and milestone M0.9.1

Besides the fact that it looks wrong, does anything bad happen because of this?

No functions are broken because of this. However, the display problem appears on several windows where local directory path is shown, like mail server setting window, local folder account setting window and News server setting window. And it can be reproduced by either log on system using a non-ASCII username or launching browser using a non-ASCII profile name, which is pretty common among non-English spoken users.

marking nsbeta1+ and moving to 0.9.2

Changing QA Contact to ji.

All platforms.

moving to 0.9.3

moving to 0.9.4

*** Bug 93023 has been marked as a duplicate of this bug. ***

Mail news triage meeting --> .9.5

Marking nsbranch- as it was decided in the August bug triage that we wouldn't have eenough time in eMojo to fix this. Let's revisit for MachV.

moving to 0.9.6

really moving to 0.9.6

moving to 1.0

Nominating for nsbeta1, this is very ugly.

Why was this left unfixed while bug 57762 was fixed?

See also bug 72736, and bug 92109.

*** Bug 138350 has been marked as a duplicate of this bug. ***

*** Bug 142917 has been marked as a duplicate of this bug. ***

move nsbeta1- to nsbeta1, please consider this as nsbeta1+ adt3 for m1.2final release

*** Bug 158588 has been marked as a duplicate of this bug. ***

Paths to helper apps are affected, too. 2002091014 trunk for MacOS9.x.

Racham, would you like to reassign this to me? We decided at the intl bug triage meeting that we would like to fix this for the next release.

reassigning to smontagu

changing qa contact

i18n triage team: nsbeta1-

*** Bug 221742 has been marked as a duplicate of this bug. ***

The bug here is that nsifilespecs only do native chars, so Javascript can't handle them. Easy fix for now is to add unicode queries and sets for nsifilespec.

Comment on attachment 133046 [details] [diff] [review] Fix for problem how about just converting to use nsIFile?

> how about just converting to use nsIFile Ha ha. Seriously. I investigated this a little bit and the directory references come from deep inside mailnews, so this would be nontrivial. I'm not in a position where I can remove nsifilespec from all of mailnews for this bug. So I'd like to do a quick fix for this.

Comment on attachment 133046 [details] [diff] [review] Fix for problem Can you do this convertion in JS without adding new methods to nsFileSpec? I would rather not add any new methods to this interface, but if we must, we must.

the problem is that the conversion has to be to the file system charset using the OS method of converting to that charset. I could do unicode conversions in Javascript, but I wouldn't know what charset to convert to. By using the code that was added to nsifile, I'm guaranteed to be doing the right thing(TM) with regards to native file system charset.

Comment on attachment 133046 [details] [diff] [review] Fix for problem r=dougt.

mkaply, is this patch ready to go for the trunk? I can drive it in if you think it is.

I definitely think it is. I've no idea why I didn't check it in previously. I can't checkin over the holiday, so if you could get it in, that would be great.

I checked this into the 1.7a trunk.

>+ wstring getUnicodePath(); >+ void setUnicodePath(in wstring aUnicodePath); Umm... this should have been attribute wstring unicodePath; surely?

Why not just use AString to avoid explicit strdup and null-checking? This is not used in any speed-critical place, is it? + native = mFileSpec.GetNativePathCString(); + NS_CopyNativeToUnicode(native, unicode); + *aUnicodePath = nsCRT::strdup(unicode.get()); + if (!*aUnicodePath) + return NS_ERROR_OUT_OF_MEMORY;

Comment on attachment 138410 [details] [diff] [review] Use attribute AString unicodePath; Thanks for cleaning this up. This looks much better.

Comment on attachment 138410 [details] [diff] [review] Use attribute AString unicodePath; r=mkaply

Comment on attachment 138384 [details] [diff] [review] Use attribute wstring unicodePath; clearing obsolete requests

Fix checked in, thanks especially to jshin, it's always good to be able to remove code from mozilla ;-)

*** Bug 228890 has been marked as a duplicate of this bug. ***

*** Bug 221908 has been marked as a duplicate of this bug. ***