bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Installation failed when installing under some locales on RH Linux

VERIFIED FIXED

Status

()

Core
Internationalization
--
major
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Rui Xu, Assigned: Shanjian Li)

Tracking

({intl})

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [m5+])

Attachments

(1 attachment, 2 obsolete attachments)

4.39 KB, patch
Shanjian Li
: review+
Scott MacGregor
: superreview+
Details | Diff | Splinter Review
(Reporter)

Description

16 years ago
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 $@
(Reporter)

Updated

16 years ago
Keywords: intl
(Reporter)

Updated

16 years ago
Summary: Installation failed when installing under some locales → Installation failed when installing under some locales on RH Linux
(Assignee)

Comment 1

16 years ago
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

16 years ago
shanjian
Assignee: yokoyama → shanjian
Keywords: nsbeta1+
(Assignee)

Comment 3

16 years ago
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. 

(Assignee)

Comment 4

16 years ago
Created attachment 82884 [details] [diff] [review]
patch

This patch removed the dependency on libuconv for unix.

Comment 5

16 years ago
Can we get r=/sr= on this?
(Assignee)

Comment 6

16 years ago
Created attachment 82890 [details] [diff] [review]
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.
Attachment #82884 - Attachment is obsolete: true
(Assignee)

Comment 7

16 years ago
Created attachment 82891 [details] [diff] [review]
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.
(Assignee)

Updated

16 years ago
Attachment #82890 - Attachment is obsolete: true

Comment 8

16 years ago
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. 
(Assignee)

Comment 9

16 years ago
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. 

Status: NEW → ASSIGNED
(Assignee)

Comment 10

16 years ago
I just called syd over the phone, and explained the code to him. He gave r=syd. 
(Assignee)

Updated

16 years ago
Attachment #82891 - Flags: review+

Updated

16 years ago
Whiteboard: [adt1] [ETA 05/09]

Updated

16 years ago
Attachment #82891 - Flags: superreview+

Comment 11

16 years ago
Comment on attachment 82891 [details] [diff] [review]
final patch

sr=mscott

Comment 12

16 years ago
adding adt1.0.0+.  Please check this into the branch after getting drivers approval.
Keywords: adt1.0.0+
Whiteboard: [adt1] [ETA 05/09] → [m5+]

Updated

16 years ago
Blocks: 143120

Comment 13

16 years ago
Comment on attachment 82891 [details] [diff] [review]
final patch

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #82891 - Flags: approval+
(Assignee)

Comment 14

16 years ago
fix checked in to branch. 
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 15

16 years ago
marking as fixed1.0.0, since shanjian says fix was checked into the branch.
Keywords: fixed1.0.0

Comment 16

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

Comment 17

16 years ago
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

16 years ago
*** Bug 143160 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 19

16 years ago
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

16 years ago
file bug 143283 for uconv depend on necko issue. not a short term need. but file
as a long term issue. 
(Reporter)

Comment 21

16 years ago
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
Keywords: fixed1.0.0 → verified1.0.0

Comment 22

15 years ago
From comment #21, I close this bug.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.