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.
Please report any other irregularities here.
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 $@
Summary: Installation failed when installing under some locales → Installation failed when installing under some locales on RH Linux
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.
Assignee: yokoyama → shanjian
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.
Created attachment 82884 [details] [diff] [review] patch This patch removed the dependency on libuconv for unix.
Can we get r=/sr= on this?
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
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.
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.
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
I just called syd over the phone, and explained the code to him. He gave r=syd.
adding adt1.0.0+. Please check this into the branch after getting drivers approval.
Whiteboard: [adt1] [ETA 05/09] → [m5+]
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+
fix checked in to branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
marking as fixed1.0.0, since shanjian says fix was checked into the branch.
Shanjian, could you make sure this gets testing on japanese rh system tomorrow so we can make sure there is no problem? Thank you.
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.
*** Bug 143160 has been marked as a duplicate of this bug. ***
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.
file bug 143283 for uconv depend on necko issue. not a short term need. but file as a long term issue.
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
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.