235385 - Fail to send mail if username (WinXP/2k) contains characters outside the system code page

Status: NEW

(MailNews Core :: Internationalization, defect)

Description

[Josh Harding]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

Logged into WinXP as a user whose username is spelled with Russian (CP-1251)
chars, mail fails to send.  Upon licking send, an error appears reading:

"Sending of message failed.

Unable to open the temporary file C:\DOCUME~1\###\LOCALS~1\TEMP\nsmail.html.
heck your 'Temporary Directory' setting."

Reproducible: Always
Steps to Reproduce:
1. Login to WinXP as user with non-latin username
2. Try to send mail

Actual Results:  
Error dialog is displayed:
"Sending of message failed.

Unable to open the temporary file C:\DOCUME~1\###\LOCALS~1\TEMP\nsmail.html.
heck your 'Temporary Directory' setting."

Expected Results:  
No error dialog.

My Windows profiles (where the temp dir is, not the Moz profile) is on the C:\
drive whih is formatted FAT32.

Comment 1

[Jungshik Shin]

Scott, David and Neil, does this part use nsFileSpec or nsI(Local)File? If it's
the latter, this bug depends on bug 162361. Even if it's the former, we're
moving away from ns(I)FileSpec so that it's gonna depend on bug 162361.

I'll ping wtc and leaf (NSPR owners) once more for adding UTF16 file I/O APIs to
NSPR on Windows. More and more bugs are blocked by our lack of support for
Unicode file i/o on Win 2k/XP. 
 

Comment 2

[Jungshik Shin]

I forgot to tell the reporter about a work-around. You can set the default
system locale to Russian and  you'd not have the problem. On Win XP, it's in
Control Panel | Regional (?) Setting | 'Code page to use for non-Unicode
program' (or something like that). Of course, this doesn't work if you share
your computer with other people whose usernames are in, say, Japanese or Thai. 

Comment 3

[Josh Harding]

It's a shared computer so changing the default locale isn't an option, but in
poking around, I found an alternate workaround:

Change the TEMP and TMP env vars from the system control panel to point to a
non-unicode path.

As my C: drive is FAT32, security is moot anyway so moving temp files outside
the user's profile doesn't sacrifice privacy.

Comment 4

[[e-mail]]

So does this mean we need a unicode-safe getenv() too?

Comment 5

[Roland Mainz]

[e-mail] wrote:
> So does this mean we need a unicode-safe getenv() too?

Mozilla already has support for unicode-safe getenv() via the nsIEnvironment
interface.

Comment 6

[Jungshik Shin]

re: comment #3: sure, that's another way to work around the problem. BTW,
changing the default system code page to Russian(Windows-1251) on en-US windows
doesn't turn all your menus into Russian. On en-US Windows, they'll stay in
English. So, if that's your concern, you don't have to worry about it unless
your colleagues have user names not covered by Windows-1251. But, if there are
non-Unicode programs to run, you can't switch the default system code page. 

re comment #4 and #5: Having Unicode-aware environment variables alone doesn't
fix this problem (well, I don't have to tell you this because you must be well
aware of that). We need to fix bug 162361 and a couple of related bugs.