84384 - Can't create profiles in directories with non-ASCII characters

Status: RESOLVED WORKSFORME

(Core :: Internationalization, defect)

Description

[Chad Austin]

See bug 83345.

Even though the crasher is fixed, you cannot create profiles in directories 
that use Kanji characters (or characters that are converted to ? in Mozilla).

I'm not really sure how to word this bug in the general case, so I'll include a 
specific instructions on how to reproduce it:

1) Run the program attached to bug 83345 (it will create a directory in your C: 
drive)
2) Start the profile manager
3) Try to create a profile within that directory
4) Click Finish

Actual result: nothing happens (dialog doesn't close)

Expected result: dialog box closes and profile is created

Comment 1

[nhottanscp]

I think this is a current restriction of nsLocalFile which supports OS charset 
only.
Chad, your environment is non JA localized windows, right?

Comment 2

[Chad Austin]

English Windows 2000 Professional

Comment 3

[nhottanscp]

Change component to i18n.
Correction, not a restriction of nsLocalFile, it's nsFilePicker.
SHGetPathFromIDList returns path name in char*, we could use API which uses 
LPWSTR if that's available.

http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsFilePicker.cpp#118
118       result = ::SHGetPathFromIDList(list, (LPSTR)fileBuffer);

Comment 4

[Chad Austin]

SHGetPathFromIDListW

I have a feeling it isn't supported on Win9x, so we'll have to use GetProcAddress.

(it isn't in the copy of MSDN I have, it's in the header)

Comment 5

[Chad Austin]

I've done some work on this bug...  I switched the win32 nsIFilePicker to use
Unicode paths (if the OS supports them), but nsILocalFile::initWithUnicodePath()
doesn't work as I thought it would.  It can't find a conversion from Unicode to
ASCII for a character (why is it doing this?) it just stops, so selecting
C:\???? truncates it to C:\.

Does nsILocalFile use wide-character file I/O routines if the filesystem
supports them?

I'll attach the changes I've made so far.

Comment 6

[Chad Austin]

Attachment: preliminary patch

Comment 7

[Teruko Kobayashi]

Changed QA contact to [e-mail].  

Comment 8

[nhottanscp]

Does the conversion happens at nsILocalFile::initWithUnicodePath()?
That looks like an issue in nsILocalFile (a separate bug). I assume that
nsILocalFile prepares for a name in char* to convert from unicode to OS charset
(I don't think it's converting to ASCII). I think nsILocalFile could delay the
conversion until it is requested to return char* representation of the path/file
name.

Comment 9

[Chad Austin]

Yes, you're right.  It converts to the filesystem charset, not ASCII.  However,
Windows NT and 2000 can store directories and filenames directly in Unicode, so
we wouldn't need to do any conversion (correct me if I'm wrong).

I'll file a new bug on the nsILocalFile issue.

Comment 10

[nhottanscp]

>so we wouldn't need to do any conversion
Unless the client requests it. There are methods with string, like getpath,
getleafName etc. in nsIFile. The conversion is needed for those cases.

Comment 11

[Frank Tang]

I think this is a little too risky. move to future. 

Comment 12

[nhottanscp]

Reassign to yokoyama.

Comment 13

[Roy Yokoyama]

Accepting.

Comment 14

[Andreas Becker]

mass change, switching qa contact from jonrubin to ruixu.

Comment 16

[Dženan Zukić]

I have opened new bug, bug 440686 (besides from sending few crash reports before that)

Comment 17

[(not currently active) Ted Mielczarek]

I don't think this bug is valid anymore. Profiles with non-ascii characters work fine for me, we made quite a few fixes to make this work. See bug 396052, bug 396199. There is still bug 413171 outstanding, but that's a separate issue.