Closed Bug 61031 Opened 24 years ago Closed 24 years ago

Mozilla not start on Macs with CE (Central European) script!

Categories

(Core :: Internationalization, defect, P1)

PowerPC
Mac System 9.x
defect

Tracking

()

VERIFIED FIXED
mozilla0.8

People

(Reporter: formanek, Assigned: ftang)

References

Details

(Keywords: intl, Whiteboard: relnote-user)

Attachments

(5 files)

Major problem! Mozilla M18 and Netscape 6 contain a bug that prevents them from launching under Mac OS 8.6 and Mac OS 9 (inclusive 9.0.4) if the CE (Central European) language script is active !!! The same problem is with the native (localized) version of Mac OS CZ1-8.6 and MacOS CZ1-9.0.4 Mozilla starts to boot -- if this is the first boot on the machine, the component registration will be executed - and after the registration, the application quits itself gracefully without any error message or dialog (even in the case of MacsBug being installed). In the case of a repetitive boot the app quits after aproximatelly 1-2 seconds... If the CE script is of, you can launch Mozilla/Netscape 6 safely... If the CE script is then activated, Mozilla/Netscape 6 goes into debugger during launch (we are sending the StdLog to news)! This bug started appearing in M18 (Netscape PR3) -- M17 works well on the same machine! This bug was tested and reproduced on several machines including G3, G4, iMac, PowerMac 9500 -- always compleely identical crash. Reference machine: iMac DV SE 400 MHz 256 MB RAM 13 GB HDD Mac OS 9.0.4 US (active CE script) or Mac OS CZ1-9.0.4 QuickTime 4.1.2 M18 -- several nightly builds tested --> cannot launch Netscape 6 -- official release --> cannot launch Please, do fix this problem prioritely! It prevents us using Mozilla on any computer in Czech or Slovak Republic, Poland or Hungary. Our localization process is also halted as we cannot check our work. PowerPC 740/750 Registers CR0 CR1 CR2 CR3 CR4 CR5 CR6 CR7 PC = 40820008 CR 0010 0010 0000 0000 0000 0000 0100 1000 LR = 1E897DD0 <>=O XEVO CTR = 40820008 MSR = 00000000 SOC Compare Count Int = 0 XER 000 00 00 MQ = 00000000 R0 = 40820008 R8 = 0E244BA8 R16 = 00000000 R24 = 0E243F00 SP = 0F22B760 R9 = 00000001 R17 = 00000000 R25 = 00000000 TOC = 38A00000 R10 = 00000001 R18 = 00000000 R26 = 0F22CB38 R3 = 00000000 R11 = 00000001 R19 = 0E3337C8 R27 = 00000000 R4 = 0F22B850 R12 = 00141568 R20 = 0E46D8F8 R28 = 00000000 R5 = 0E3B1110 R13 = 00000000 R21 = 0F22CB38 R29 = 0F22B850 R6 = 00029B68 R14 = 00000000 R22 = 0F22CB44 R30 = 0F22C3A4 R7 = 00000066 R15 = 00000000 R23 = 1E75E6B9 R31 = 0E243F00 Unable to access that address Heap zones #1 Mod 17457K 00002800 to 0110EF0F SysZone^ #2 Mod 6K 00026DB0 to 0002896F ROM read-only zone #3 Mod 234392K 0110EF10 to 0F5F529F Process Manager zone #4 Mod 16197K 0E210340 to 0F1E1A3F “Mozilla” ApplZone^ TheZone^ TargetZone #5 Mod 18K 0F2E75D0 to 0F2EBE7F #6 Mod 954K 0F301BA0 to 0F3F069F “Finder” #7 Mod 99K 0F405000 to 0F41DEFF “Time Synchronizer” #8 Mod 265K 0F428860 to 0F46AF5F “iDo Script Scheduler Extension” #9 Mod 361K 0F47F8C0 to 0F4D9FBF “Folder Actions” #10 Mod 78K 0F50E180 to 0F521BAF “DVD AutoLauncher” #11 Mod 153K 0F531DE0 to 0F5584DF “Control Strip Extension” #12 Mod 169K 0F56AE40 to 0F59553F “Connectix Network Copy” #13 Mod 4095K 10100000 to 104FFFCF #14 Mod 144K 102413D0 to 102653CF #15 Mod 94K 102C74A0 to 102DF07F
Jakub Formanek, can you test a current build. Thanks.
Assignee: asa → rchen
Component: Browser-General → Localization
QA Contact: doronr → teruko
Giving to Conrad on the basis of the log: Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 1EAECB94 0F22D880 PPC 1EAD74D0 main+00130 0F22D820 PPC 1EAD6884 main1(int, char**, nsISupports*)+006DC 0F22D570 PPC 1E894560 nsAppShellService::CreateHiddenWindow()+000FC 0F22D4B0 PPC 1E895A94 nsAppShellService::JustCreateTopWindow(nsIXULWindow* , nsIURI*, i nt, int, unsigned int, int, int, nsIXULWindow**)+001D0 0F22D410 PPC 1E888658 nsWebShellWindow::Initialize(nsIXULWindow*, nsIAppShell*, nsIURI *, int, int, int, unsigned int, int, int, nsWidgetInitData&)+0068C 0F22D210 PPC 1E700FA0 LoadURI__10nsDocShellFPCwUi+003AC 0F22CF50 PPC 1E6F658C nsDocShell::LoadURI(nsIURI*, nsIDocShellLoadInfo*, unsigned int) +003CC 0F22CE90 PPC 1E70A7A0 nsDocShell::InternalLoad(nsIURI*, nsIURI*, nsISupports*, int, in t, const char*, nsIInputStream*, nsIInputStream*, unsigned int, nsISHEntry*)+ 00290 0F22CE10 PPC 1E70D204 nsDocShell::DoURILoad(nsIURI*, nsIURI*, nsISupports* , int, int, const char*, nsIInputStream*, nsIInputStream*)+002D8 0F22CCB0 PPC 1E70E648 NS_OpenURI(nsIChannel**, nsIURI*, nsIIOService*, nsILoadGroup*, nsIInterfaceRequestor*, unsigned int, unsigned int, unsigned int)+000AC 0F22CC20 PPC 1DAFE004 nsIOService::NewChannelFromURI(nsIURI*, nsIChannel** )+0011C 0F22CB90 PPC 1E75ABEC nsChromeProtocolHandler::NewChannel(nsIURI*, nsIChannel**)+0036C 0F22C900 PPC 1E7408B8 nsChromeRegistry::ConvertChromeURL(nsIURI*, char**)+ 00154 0F22C550 PPC 1E74E278 nsChromeRegistry::GetProfileRoot(nsCString&)+00098 0F22C400 PPC 1E899680 nsFileLocator::GetFileLocation(unsigned int, nsIFileSpec**)+0007 0 0F22C360 PPC 1E898BC8 nsSpecialFileSpec::operator= (nsSpecialFileSpec::Type)+003D8
Assignee: rchen → ccarlen
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: nsmac2
Attached file MacsBug log (deleted) —
Henri Sivonen also mentions that this problem affects the Hebrew script too.
URL: --
You aren't, by any chance, using the Central European (CE) script (defined in the Keyboards control panel), are you? If so, possible duplicate of bug 61031.
Wrong bug. Sorry.
Current state: Installer: MacMozillaInstaller.sea.bin 23-Nov-2000 08:34 -- instalator always crashes at the same time - error -47 -- install is not possible trunk: mozilla-mac-Mtrunk.sea.bin 23-Nov-2000 08:28 vers.: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20001123 08 -- after install to a system with active CE script when trying to convert user profile from Netscape 475 always crashes into debugger (stdlog2 included) -- if everything from Netscape 475 and previous Mozilla install was removed the program quits as described earlier. -- if CE script is deactivated and then after restart Mozilla (2000112308) installed again everything works as it should! -- if I switch to CE script then after restart Mozilla starts OK! <- was not posible before! -- important find! -- if you remove ".../Documents/Mozilla/Application Registry" -- mozilla stops booting (the same problem as described before) -- Mozilla recreates this file automatically -- but probably here is the mistake -- if the original file is put back in place (Application Registry) generated originally on a System without an active CE script -- Mozilla works again! Jakub
Attached file StdLog2 (deleted) —
I sense that this is more to do with internationalization than with localization -- component changed accordingly. This may be related to a different way Mozilla supports font/script resources for CE. Should be looked at by ftang@netscape.com. CC'ing nhotta and yokoyama because he is on a an extended break for now. BTW, there is no problem with Japanese Language support/keyboard. Jakub, are you using ceska or slovenska keyboards? (no accents on these workds, sorry.)
Component: Localization → Internationalization
Katsuhiko - Jakub is using the Ceska keyboard (if I can speak for him - we share the workplace over here).
Keywords: relnoteRTM
Whiteboard: relnote-user
There is a bug in nsSpecialSystemDirectory. Roy is working on it (bug 58679).
Jakub, can you check to see if your OS creates a "Preference" folder in Czech rather than in English? If so, this problem could be resolved by Roy's fix in Bug 58679.
Jakub, Can you also check if a "Documents" folder is being created on the root of the startup disk? There is some code in XPCOM which makes that dir with a hardcoded english string if it does not exist.
Bug 58679 seems to cover Windows only.
I use a US system with active CE script. Folders like "Preferences" and "Documents" are on their places and if not then Mozilla recreates them -- that's OK... I use Ceska or Czech or US keyboard -- it doesn't make any difference The problem lies probably somewhere around "Application Registry" (see above). This file is created during the install different when CE script is active then when installing under US script. If created with US script, everything works. If you remove it temporarily and Mozilla recreates it with CE script active then Mozilla will refuse to boot... If I only replace this "Application Registry" with the original one (overwriting the newer one) it works all right again... The problem with a completely localized MacOS (as in contrast to the US system with CE script) seems completely identical to me.
*** Bug 60839 has been marked as a duplicate of this bug. ***
We tried Jakub's steps under US OS9 and was not able to reproduce the problem. Here's what I did: 1. Deleted "System Folder | Preferences | Mozilla.registry 2. Deleted HD: Document or HD:Mozilla directory 3. Also deleted Application registry file wihtin the directory under 2. 4. Turn on the Czech keyboard. (Befoe doing this, I changed Control Panel | Appearance | Fonts to Helvetica-CE for display in Finder. 5. Start up Mozilla latest or NS6-released build. It starts up OK. Jakub, can you break down what you're doing to the steps like the above?
Actually - changing the keyboard is not enough IMO. What Jakub Formanek (and many other people are describing) is a different SCRIPT being activated. You get a different OS script either with a localized version of MacOS or by using a utillity ScriptSwitcher to switch to another script on a US system. (You have to have the script file installed in System though.) So solely turning on the Czech keyboard and Helvetica CE in Appearance will not do the trick, I would think...
The way to reproduce the error: 1 -- download mozilla-macMTest (Mozilla 0.6) 2 -- switch to the CE script on a US MacOS and restart the computer (use ScriptSwitcher) 3 -- download, extract and run Mozilla 4 -- Mozilla displays the splash screen and after finishing component registration it simply quits. Without any warning or error. 5 -- if you switch back to Roman script and restart Mozilla will run fine again.
Jakub, I got ScriptSwitcher but now of course need the CE script. How can I get this so I can install on my US system and use ScriptSwitcher? I can't read anything on www.apple.cz ;-)
CE Script is on any Mac OS 9 install CD-ROMs exemplary: iMac Install CD/Software Installers/Language Kits/Language Scripts/CentralEuropean <-- CE Script and I create new attachment with this file...
CE Script is on any Mac OS 9 install CD-ROMs exemplary: iMac Install CD/Software Installers/Language Kits/Language Scripts/CentralEuropean <-- CE Script and I create new attachment with this file...
Attached file CentralEuropean Script (CE) (deleted) —
OK, so I installed the CE language kit from the MacOS CD. Using ScriptSwitcher8, which I got from a link within apple.com, CE does not show up - the only additional script after instaling the CE kit is "Ethiopic." Is there a newer version of ScriptSwitcher for OS9?
yeah, this is okay... this is a bug of older ScriptSwitcher, but work fine.. (Ethiopic work same as Czech)
Jakub, can you clarify why you are using ScriptSwithcer at all? The keyboard can switch to Czech and Text Control Panel can switch the associated text behavior. Why would we need ScriptSwitcher. Is the utility recommended for OS 8.6 and OS 9.0. Maybe the real question is: what does ScriptSwitcher accomplish in the context of OS 8.6 and OS 9.0?
Jakub, your post on 2000-12-06 04:14 with respect to the "Application Registry" file is most interesting. That file stores, among other things, aliases to the profile directory for each profile entry. Alias creation and resolution should be safe from script differences, but... Can you post both copies of this file - the one with which mozilla will start and the one that won't. Make each under identical situation - deleting all profiles, profile dirs, etc. Possibly by looking at the differences between the files I can tell something.
Katsuhiko Momoi: The change of script allows to use all fonts in CE version (big and small system ones) -- appearance panel without an active CE script does not allow for this to be set. Also - the script changes date format and numbers format to CE. Also sets the national code in System. these rsrc are modified (probably there are more): itlb itlc KCHAR kcs# kcs4 kcs8 itl0 itl1 itl2 itl4 NFNT sfe# sfn# sfnt sfs# vfnt The change of keyboard does not change anything, only allows access to CE characters (with CE fonts).
Thanks for posting the registry files. The second (id=20476) has no profile list in it at all and no entry for the current profile. This means that there is probably not something wrong with the contents of the file which is script sensitive but something else is causing failure after the registry access is made but before any useful data is written to it. Still looking...
Keywords: intl
A comment on <http://www.macintouch.com/netscape6part2.html> says: I just downloaded Netscape 6 onto my brand-new 500 MHz Powerbook 2000, where I am running MacOS 9.0.4 with Hebrew enabler. It quit immediately upon starting. Using LanguageSwitch to change the primary system script to "Roman" and rebooting solved the problem. Apparently Netscape 6 (unlike its predecessor) relies on MacOS Runtime for Java: MRJ has a known problem with system scripts other than Roman. So anybody who uses a non-Roman script (Cyrillic, Hebrew, Arabic, Japanese, Chinese,...) caveat emptor. So maybe this is MRJ related?
I'll install such a system and see. Isn't CE a roman script though?
Status: NEW → ASSIGNED
Priority: P3 → P1
Target Milestone: --- → mozilla0.8
Maybe Simon means MacRoman, which is an encoding used for Latin 1 character set. CE (Central European) uses MacCE character set/encoding. So that would require a different conversion to Unicode. BTW, both MacRoman and MacCE languages use Roman-based/Latin-based script. I'm still wondering if there is a special encoding conversion related problem here. Also, someone please educate me as to what you have been referring to as "LanguageSwitch"? Is this the same as "Language Register" application that comes with Language Kits, which sets the application locale to another language? If not, where can we get this? I looked at Apple sites but could not find it.
Conrad and Katsuhiko:<P><A HREF="http://www.apple.cz/">http://www.apple.cz/</A> is Apple Czech Republic programming and producing MacOS 9.0.4 CE. They will be able to answer a lot of your questions. As far as the CE language script is concerned - no, it's not the default Roman script. Where to get it? -- look backwards on this page, there is a path on default MacOS 9 CD where to find it (Jakub Formanek mentions it). To switch between these language scripts, you need an application Script Switcher. Somebody also reported earlier on this page where to find it (if it's not on the MacOS CD). CE script is selected by selecting Ethiopian script - it's an interface bug in Script Switcher. And NO - it's not the same as changing local using Language Register.
*** Bug 63567 has been marked as a duplicate of this bug. ***
Once more: Conrad and Katsuhiko: http://www.apple.cz/ is Apple Czech Republic programming and producing MacOS 9.0.4 CE. They will be able to answer a lot of your questions. As far as the CE language script is concerned - no, it's not the default Roman script. Where to get it? -- look backwards on this page, there is a path on default MacOS 9 CD where to find it (Jakub Formanek mentions it). To switch between these language scripts, you need an application Script Switcher. Somebody also reported earlier on this page where to find it (if it's not on the MacOS CD). CE script is selected by selecting Ethiopian script - it's an interface bug in Script Switcher. And NO - it's not the same as changing local using Language Register.
Keywords: nsbeta1
I installed the Czech language kit from the OS9 CD and ScriptSwitcher. This problem does happen for me so I'll be debugging it today.
Looked into it and found this: 1) I get this assertion in initializing profile mgr: ###!!! ASSERTION: cannot find the unicode decoder: '(NS_SUCCEEDED(res) && mDecoder)', file nsLocalFileCommon.cpp, line 189 2) This is because the FS charset is determined to be x-mac-geez and we fail to find that encoder. With the czech script, region code is 56. We don't have that entry in maccharset.properties, so we try for the script code of 29. That gives x-mac-geez as the FS charset. 3) Since we can't find the unicode encoder for this, most file operations in the profile mgr, since it uses unicode heavily, are doomed. 4) nsIProfileInternal::StartupWithArgs returns an error and the app silently quits. I think this should be re-assigned to somebody in the internationalization group because, while the profile mgr suffers from this problem, it is not the cause.
Reassign to ftang.
Assignee: ccarlen → ftang
Status: ASSIGNED → NEW
Script Switcher is needed to switch language script used in System related display such as Finder. You can not have a Finder Menu in Japanese(or whatever) unless you switch primary script. ScriptSwitcher8 (that is the version you need) can be DLed from: ftp://ftp.apple.com/devworld/Tool_Chest/Localization_Tools/ScriptSwitcher8.sea.hqx
"x-mac-geez" ???? I found the problem The last 4 line in current mozilla is /intl/uconv/src/maccharset.properties script.29=x-mac-geez script.30=x-mac-ce script.31=x-mac-vietnamese script.31=x-mac-extarabic it should really be script.29=x-mac-ce script.30=x-mac-vietnamese script.31=x-mac-extarabic so it will use "x-mac-ce" for the script number 29. This is a typo I made. formanek@vol.cz: can you locate the maccharset.properties in your system and try this out ? This bug should only affect Mac vietnamese (which does not really exist) and CE (Which is general available). I think the risk to fix this is very low if we can confirm that the change did fix it.
Status: NEW → ASSIGNED
My latest fix will only impact Mac CE. It won't FIX any Arabic and Hebrew problem. That is a seperate issue. For Arabic and Hebrew. The problem is currently we didn't have a corss platform x-mac-hebrew or x-mac-arabic converter. So the init code won't work.
Frank Tang 2001-01-11 10:00 Great--that's exactly it--it works, CE script does have the code number 29--that's right! Perfect is that it also removes another bug, which I had prepared for submiting! (some characters in window titles did not display correctly). It seems this patch solves more then was thought before... but there is one more problem! If I install Mozilla 0.7 on a wholy clean computer (with no files from a previous Mozilla version) and change the file "maccharset.properties" as described above, Mozilla 0.7 crashes with an error type 2. If I let Mozilla 0.7 start without these changes, it quits immediatelly after component registration (as described in this bug :) and then patch the file accordingly--then everything works 100% OK. So--I guess there is a problem in component registration or somewhere near the first-time startup code which gets exposed with this patch. tested on: Mac OS CZ-1-9.0.4 (complete OS localization) and Mac OS 9.1 US with active CE script and Czech/Ceska keyboard layout Mozilla 0.7 "mozilla-mac-M0.7"--release both systems perform equally in all tests...
Here is the patch Index: maccharset.properties =================================================================== RCS file: /m/pub/mozilla/intl/uconv/src/maccharset.properties,v retrieving revision 1.4 diff -c -r1.4 maccharset.properties *** maccharset.properties 1999/11/06 03:23:40 1.4 --- maccharset.properties 2001/01/16 18:20:02 *************** *** 61,67 **** script.26=x-mac-tibetan script.27=x-mac-mongolian script.28=x-mac-ethiopic ! script.29=x-mac-geez ! script.30=x-mac-ce ! script.31=x-mac-vietnamese script.31=x-mac-extarabic --- 61,66 ---- script.26=x-mac-tibetan script.27=x-mac-mongolian script.28=x-mac-ethiopic ! script.29=x-mac-ce ! script.30=x-mac-vietnamese script.31=x-mac-extarabic
here is the quote from script.h so reviewer can review it smMongolian = 27, smEthiopic = 28, smGeez = 28, /* Synonym for smEthiopic*/ smCentralEuroRoman = 29, /* For Czech, Slovak, Polish, Hungarian, Baltic langs*/ smVietnamese = 30, smExtArabic = 31, /* extended Arabic*/ smUninterp = 32 /* uninterpreted symbols, e.g. palette symbols*/ };
r=nhotta
This change looks good. But what do we do about the arabic and hebrew problems? Can we default to some basic converter? Or can we use a wrapper around the Text Encoding Converter?
fix and check in CE problem.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Jakub Formanek, would you verify this bug?
VERIFIED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: