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)

Product:
Core
Component:
Internationalization
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.8

People

(Reporter: formanek, Assigned: ftang)

References

Details

(Keywords: intl, Whiteboard: relnote-user)

Attachments

(5 files)

MacsBug log
26.53 KB, text/plain
Details
StdLog2
29.58 KB, text/plain
Details
CentralEuropean Script (CE)
8.19 KB, application/octet-stream
Details
Application Registry file that allow Mozilla start on CE Script (Build 2000112308 ONLY!)
865 bytes, application/octet-stream
Details
Application Registry file which create Mozilla on CE Script, but then no launch (Build 2000112308 ONLY!)
503 bytes, application/octet-stream
Details 
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
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 — 

    
    

    
  
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...

    
    

    
  


  

    
    

    
  
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

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: