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)
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
Comment 1•24 years ago
|
||
Jakub Formanek, can you test a current build. Thanks.
Assignee: asa → rchen
Component: Browser-General → Localization
QA Contact: doronr → teruko
Comment 2•24 years ago
|
||
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
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
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.
Reporter | ||
Comment 7•24 years ago
|
||
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
Reporter | ||
Comment 8•24 years ago
|
||
Comment 9•24 years ago
|
||
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
Comment 10•24 years ago
|
||
Katsuhiko - Jakub is using the Ceska keyboard (if I can speak for him - we share the workplace over here).
Updated•24 years ago
|
Keywords: relnoteRTM
Whiteboard: relnote-user
Comment 11•24 years ago
|
||
There is a bug in nsSpecialSystemDirectory. Roy is working on it (bug 58679).
Comment 12•24 years ago
|
||
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.
Comment 13•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
Bug 58679 seems to cover Windows only.
Reporter | ||
Comment 15•24 years ago
|
||
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.
Comment 16•24 years ago
|
||
*** Bug 60839 has been marked as a duplicate of this bug. ***
Comment 17•24 years ago
|
||
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?
Comment 18•24 years ago
|
||
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...
Reporter | ||
Comment 19•24 years ago
|
||
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.
Comment 20•24 years ago
|
||
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 ;-)
Reporter | ||
Comment 21•24 years ago
|
||
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...
Reporter | ||
Comment 22•24 years ago
|
||
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...
Reporter | ||
Comment 23•24 years ago
|
||
Comment 24•24 years ago
|
||
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?
Reporter | ||
Comment 25•24 years ago
|
||
yeah, this is okay... this is a bug of older ScriptSwitcher, but work fine.. (Ethiopic work same as Czech)
Comment 26•24 years ago
|
||
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?
Comment 27•24 years ago
|
||
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.
Reporter | ||
Comment 28•24 years ago
|
||
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).
Reporter | ||
Comment 29•24 years ago
|
||
Reporter | ||
Comment 30•24 years ago
|
||
Comment 31•24 years ago
|
||
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...
Comment 32•24 years ago
|
||
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?
Comment 33•24 years ago
|
||
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
Comment 34•24 years ago
|
||
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.
Comment 35•24 years ago
|
||
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.
Comment 36•24 years ago
|
||
*** Bug 63567 has been marked as a duplicate of this bug. ***
Comment 37•24 years ago
|
||
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.
Comment 38•24 years ago
|
||
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.
Comment 39•24 years ago
|
||
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.
Comment 41•24 years ago
|
||
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
Assignee | ||
Comment 42•24 years ago
|
||
"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
Assignee | ||
Comment 43•24 years ago
|
||
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.
Reporter | ||
Comment 44•24 years ago
|
||
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...
Assignee | ||
Comment 45•24 years ago
|
||
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
Assignee | ||
Comment 46•24 years ago
|
||
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*/
};
Comment 47•24 years ago
|
||
r=nhotta
Comment 48•24 years ago
|
||
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?
Assignee | ||
Comment 49•24 years ago
|
||
fix and check in CE problem.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 50•24 years ago
|
||
Jakub Formanek, would you verify this bug?
You need to log in
before you can comment on or make changes to this bug.
Description
•