ji Reporter
	Description • 22 years ago

This bug is filed as one corresponding to
http://bugscape.netscape.com/show_bug.cgi?id=20104

Steps to reproduce:
1. Install browser in a Chinese folder on Simplified Chinese XP in Chinese locale.
2. Go to Control Pane -> Region and Language selection -> Advanced Tab
3. Change the locale to English (US) and reboot the system
4. Click on Netscp.exe installed at step 1.
Browser just simply doesn't launch, profile manager doesn't come up. An error
message (i guess from Windows) is popped up saying that Netscp.exe encountered
problems and needs to be closed.

	Jaime Rodriguez, Jr.
	Comment 1 • 22 years ago

This is needed by a mjor embeding customer. Marking as nsbeta1+/topembed+.

	Frank Tang
	Comment 2 • 22 years ago

roy, can you try this with the NSRP / XPCOM IO unicode change on the trunk to
see this will be fixed by that or not. 

	Roy Yokoyama
	Comment 3 • 22 years ago

bulk milestone change

	Roy Yokoyama
	Comment 4 • 22 years ago

We need PR_LoadLibraryUCS2() in order to suppor this.

	Roy Yokoyama
	Comment 5 • 22 years ago

Little busy until now. I'm on this.

	bobj
	Comment 6 • 22 years ago

This is no longer needed for a major embedding customer.
Changing to nsbeta1-, topembed-.

This bug is related to completing the work to make Mozilla a Unicode app.
Reassigned to ftang for now...

	Steve-o
	Comment 7 • 20 years ago

I have a similar problem appears to be related.  

Windows XP Pro US English edition with Traditional Chinese MUI and locale set to
"Chinese - Hong Kong SAR", neither a previously installed Firefox 1.0-PR
(English) or a new Mozilla 1.7.3 installation program (!) will run, although no
error popup or anything will appear.

	Frank Tang
	Comment 8 • 20 years ago

what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs
for 2 years. And they are still there. Just close them as won't fix to clean up.

	Travis Chase
	Comment 9 • 20 years ago

Mass Reassign Please excuse the spam

	Travis Chase
	Comment 10 • 20 years ago

Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him

	Travis Chase
	Comment 11 • 20 years ago

Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam

	Jungshik Shin Assignee
	Comment 12 • 18 years ago

This may or may not have been fixed by bug 162361. Perhaps not because the module registration code uses 'native' (as opposed to Unicode) methods of nsILocalFile if I recall correctly. 

	Benjamin Smedberg
	Comment 13 • 18 years ago

It uses nsILocalFile.load. If that is broken, we should fix it (I thought that the PR_LibSpec_PathNameU code from bug 326168 was supposed to fix it).

http://lxr.mozilla.org/mozilla/source/xpcom/components/nsNativeComponentLoader.cpp#138

	Jungshik Shin Assignee
	Comment 14 • 18 years ago

(In reply to comment #13)
> It uses nsILocalFile.load. If that is broken, we should fix it (I thought that
> the PR_LibSpec_PathNameU code from bug 326168 was supposed to fix it).

That's fixed for sure. However, there are other component-handling routines  that use 'native' methods. For instance, |nsComponentManagerImpl::WritePersistentRegistry| stores  component paths in the system default encoding. In the situation being dealt with here, that wouldn't work, would it? Most of those cases are XP-code so that either we need to add '#ifdef XP_WIN' or we need to come up with a clever way to deal with it an XP-way. Storing the component paths in UTF-8 everywhere (or only explicitly on Windows) is a possibility, but it may affect the start-up time. Whatever we do,
it seems like some #ifdef's are unavoidable....

	Jungshik Shin Assignee
	Comment 15 • 18 years ago

In addition to the issues mentioned in comment #14, |GetModuleFileNameA(0, ...)| is used in many places (most of them are irrelevant to this bug, though)

This one is isolated and easy to fix. 

http://lxr.mozilla.org/seamonkey/source/toolkit/xre/nsAppRunner.cpp#1070

1070 #ifdef XP_WIN
1071   char exePath[MAXPATHLEN];
1072 
1073   if (!::GetModuleFileName(0, exePath, MAXPATHLEN))
1074     return NS_ERROR_FAILURE;
1075 
1076   rv = NS_NewNativeLocalFile(nsDependentCString(exePath), PR_TRUE,
1077                              getter_AddRefs(lf));
1078   if (NS_FAILED(rv))
1079     return rv;
1080 

	(not currently active) Ted Mielczarek
	Comment 16 • 15 years ago

I think we fixed most of this, but there's still a bug on NSS not accepting Unicode pathnames.

	Sylvestre Ledru [:Sylvestre]
	Comment 17 • 6 years ago

Moving to p3 because no activity for at least 24 weeks.