169712 - Browser doesn't launch when install path contains Chinese and system is switched to English locale later

Status: RESOLVED INCOMPLETE

(Core :: Internationalization, defect, P3)

Description

[ji]

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.

Comment 1

[Jaime Rodriguez, Jr.]

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

Comment 2

[Frank Tang]

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. 

Comment 3

[Roy Yokoyama]

bulk milestone change

Comment 4

[Roy Yokoyama]

We need PR_LoadLibraryUCS2() in order to suppor this.

Comment 5

[Roy Yokoyama]

Little busy until now. I'm on this.

Comment 6

[bobj]

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...

Comment 7

[Steve-o]

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.

Comment 8

[Frank Tang]

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.

Comment 9

[Travis Chase]

Mass Reassign Please excuse the spam

Comment 10

[Travis Chase]

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

Comment 11

[Travis Chase]

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

Comment 12

[Jungshik Shin]

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. 

Comment 13

[Benjamin Smedberg]

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

Comment 14

[Jungshik Shin]

(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....

Comment 15

[Jungshik Shin]

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 

Comment 16

[(not currently active) Ted Mielczarek]

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

Comment 17

[Sylvestre Ledru [:Sylvestre]]

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

Comment 18

[Andrei Purice]

Marking this as Resolved > Incomplete since the last real activity on this issue was 12 years ago (reported for Windows XP) and it might not be relevant anymore.
Feel free to re-open it if it's not the case and the issue is still relevant.