143132 - Installation failed when installing under some locales on RH Linux

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Rui Xu]

Build: 2002-05-08-10-1.0.0
OS: JA RH 7.1 and RH 7.2

This is separated for bug 142850.

When installing under locale ja_JP.SJIS and zh_TW.Big5 on JA RH 7.1 and RH 7.2, got the following error and the installation failed. 

Warning: MOZILLA_FIVE_HOME not set. 
./netscape-installer: line 45: 1583 segmentation fault.  
./netscape-installer-bin $@

Comment 1

[Shanjian Li]

On RH7.2, nl_langinfo(CODESET) returns ANSI_X3.4-1968, which is an alias of
us-ascii. I believe this cause the problem, but don't know why yet. 
We should handle such situation gracefully. 

Comment 2

[Frank Tang]

shanjian

Comment 3

[Shanjian Li]

The problem is because we add the dependency on libuconv to do some charset
conversion. Part of the code is try to identify platform charset, which need to
search some property file. This function relys on necko module. I don't know at
this point why nsURLProperties::nsURLProperties
 could not return gracefully. I guess it might not be a good option to add necko
and probably some other modules to xpcom.xpi. We don't know if that will end
there. I am suggesting 2 options here:
1, Set LANG in mozilla-installer to be en_US, and set it back when script exit.
We will have problem in localized installation. This not a good option. 
2, Remove the dependency on libuconv. It seems that we only do the conversion
for path, and it is not really necessary to be able to handle native character
in path. If we allow user use native path, they will have problem accessing it
in other locale. People rarely do that and this is an acceptable option. 

I am working on a patch use option 2. 

Comment 4

[Shanjian Li]

Attachment: patch

This patch removed the dependency on libuconv for unix.

Comment 5

[scottputterman]

Can we get r=/sr= on this?

Comment 6

[Shanjian Li]

Attachment: patch

Almost same as above, add some comment and remove warning for unix. 
It also move those conversion routine back to browser xpi, since we 
don't need it in xpcom.xpi anymore.

Comment 7

[Shanjian Li]

Attachment: final patch

Being greedy, I move the other conversion related file to browser.xpi. This
patch is final, I don't see any more improvement possible.

Comment 8

[Syd Logan]

Ok, so, my question is this. We have seen random flakiness on Linux en-US
systems, some people install OK, others crash. It implies someone is not
respecting a failure code or checking a NULL pointer or something like that.
This dependency breaking might be more easily triggering on some people's Linux
machines, but is there a chance that by not breaking the dependency on Mac and
Windows that we will cause some number of people to run into the crash on those
platforms too? Or is there something specific about this code that requires we
only need to break the dependency for Linux. 

Comment 9

[Shanjian Li]

I will try to answer your question. On windows ( and probably mac), the
character query and conversion is performed using system API. Since unix does
not have this kind of unicode support buildin, we have to use our own
implementation. Our unicode conversion module has dependency on something else,
necko for example. It is a problem not be able to handle it gracefully when
necko module is not there, and that's something we need to find out in future.
But to add necko to xpcom.xpi sounds like a risky option, since necko may have
dependency on something else and I certainly do want to see another stopper bug. 

When do we need the conversion? For file/foler path. As what I said in comment
#3, that is not really necessary. So the dependency on unicode conversion can be
removed. 

Comment 10

[Shanjian Li]

I just called syd over the phone, and explained the code to him. He gave r=syd. 

Comment 11

[Scott MacGregor]

Comment on attachment 82891 [details] [diff] [review]
final patch

sr=mscott

Comment 12

[scottputterman]

adding adt1.0.0+.  Please check this into the branch after getting drivers approval.

Comment 13

[Asa Dotzler [:asa]]

Comment on attachment 82891 [details] [diff] [review]
final patch

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 14

[Shanjian Li]

fix checked in to branch. 

Comment 15

[Jaime Rodriguez, Jr.]

marking as fixed1.0.0, since shanjian says fix was checked into the branch.

Comment 16

[Syd Logan]

Shanjian, could you make sure this gets testing on japanese rh system tomorrow
so we can make sure there is no problem? Thank you. 

Comment 17

[Rui Xu]

I will test it on Japanese RH 7.1 and RH 7.2 with supported locales, and will 
spot check with some non-supported locales. 

Comment 18

[John Morrison]

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

Comment 19

[Rui Xu]

I tried to install under the following locales so far, it is not reproducible 
with 1.0 branch build 2002-05-09 on JA RH Linux 7.1. 

   ja_JP.eucJP
   zh_CN.GB2312
   ko_KR.euckr
   korean.euc
   ja_JP.SJIS
   zh_TW.Big5
   ja_JP
   C
   en
   en_US

I will try the rest areas on RH 7.2.

Comment 20

[Frank Tang]

file bug 143283 for uconv depend on necko issue. not a short term need. but file
as a long term issue. 

Comment 21

[Rui Xu]

Tested the following rest areas, this bug is not reproducible with 1.0 branch 
build 2002-05-09.

1. On JA RH Linux 7.1: 
   ja_JP.eucJPutf8, japanese, japanese.euc, japanese.sjis
   zh_CN, zh_CN.gbk, zh_CN.gb18030, zh_CN.utf8
   zh_TW, zh_TW.euctw, zh_TW.utf8, zh_HK, zh_HK.utf8 
   ko_KR, ko_KR.utf8, korean

2. On RH Linux 7.2: 
   ja_JP, ja_JP.eucJP, ja_JP.eucJPutf8, ja_JP.SJIS, japanese, japanese.euc, 
japanese.sjis
   zh_CN, zh_CN.GB2312, zh_CN.gbk, zh_CN.utf8
   zh_TW, zh_TW.Big5, zh_TW.euctw, zh_HK, zh_HK.utf8 
   ko_KR, ko_KR.euckr, ko_KR.utf8, korean, korean.euc
   C, en, en_US, en_HK

Comment 22

[Teruko Kobayashi]

From comment #21, I close this bug.