Closed Bug 152383 Opened 22 years ago Closed 22 years ago

Mac OS 9 stub and Full installer fails to launch app after install

Categories

(SeaMonkey :: Installer, defect)

Product:
SeaMonkey
Component:
Installer
Platform:
PowerPC
Mac System 9.x
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: rvelasco, Assigned: dougt)

References

Details

(Keywords: regression)

Attachments

(1 file)

install log file for Mozilla nightly trunk bits (2002-06-17-08)
4.84 KB, text/plain
Details 
Using todays 2002-06-17-08 commercial trunk builds, browser fails to launch
after installation.  Seeing this with both stub and blob installers (gchan
tested the stub).

Steps to reproduce:
1. Clean uninstall Mac OS 9 build
2. Download todays trunk build
2. run Installer with all components checked

Expected Result:
Browser starts after all packages have been installed.

Actual Result:
Splash screen appears and browser quits on startup.

Sidenote:
profile migration does not appear either if you have 4.x installed.

I'll mark the severity as critical, but I think it should be blocker since it
doesn't launch at all.
QA Contact: bugzilla → ktrina
Does this happen with the Mozilla build? If not this should be a bugscape bug.
Has any new component been added recently? Maybe something didn't get packaged.
Assignee: dveditz → syd
Using Mozilla 2002-06-17-08-trunk builds the stub installer wouldn't even start
to download (it kept defaulting to pause everytime I hit resume) and the full
installer downloaded but wouldn't launch as Rodney describes.
Using Netscape 2002-06-17-08-trunk builds the stub and full installers
downloaded and launched fine. And my 4.x profile was migrated as well. I
wouldn't move this to Bugscape. Rodney, is this what you are seeing?
What we were seeing was that commercial stub/full installers
installed fine. But once we clicked on exe or profile
manager you would see trunk splash screen, then it would
quit.

We couldn't migrate 4.x profiles or create new profiles at all.
Okay I tried testing this problem on a Mozilla nightly build.  Attached is my
install log file for this mornings mozilla trunk build.  I didn't even get
through the install as you can see from my log file.  

K'trina, to answer your question, I am still seeing the problem on the todays
trunk builds as well as yesterdays commercial trunk builds (2002061608)
adding more xpinstall gurus to Cc since syd is on vacation.  

Apparently if you had a working build with  

System Folder:Preferences:Mozilla Versions 

file already there, the installation would complete and the build would launch.
 Following the Mozilla uninstallation guidelines 

http://www.mozilla.org/releases/mozilla1.1a/#uninstall

removing the file (along with the other files) causes the build to fail to
launch after installation.  I was able to replicate this on k'trina's machine.
Doug mucked with libreg as part of his bug 48888 fix, maybe something he did
broke the creation of the Mozilla Versions file.

Hard to believe Mozilla Versions has anything to do with it, though, based on
where the install log says its failing.
Keywords: regression
marking a smoketest blocker.... fails to launch with mac os9 commercial build
2002-06-18-03-trunk
Severity: critical → blocker
Keywords: smoketest
Did the installers work Friday morning?  What about Saturday morning?
Assignee: syd → dougt
fridays build launched...saturdays fails
tracy, Does this only fail on mac os 9?   
yes
tracy, is this isolated to a installer problem?  For example, can you try the
embedding client?

http://ftp36.newaol.com/pub/mozilla/nightly/2002-06-18-03-trunk/Mac-Embed.sit.bin
I asked conrad carlen to test the embedding test application on the mac.  This
would show, at least, xpcom startup works from embedding.  Aim conversation:

ConradCarlen: WFM on OS9 and X
DougTnscp: nice!
DougTnscp: so, you could launch mac embed on both x and os9
ConradCarlen: y
DougTnscp: which did you run first?
ConradCarlen: ran OSX first, but delted the comp reg the 2nd time on 9
DougTnscp: what file did you delete?
DougTnscp: :-)
DougTnscp: there is a new file....
DougTnscp: dist/components/compreg.dat
ConradCarlen: ah - not that one - let me try that
DougTnscp: ty.
DougTnscp: (also, take a look at the format when you get a chance.... nice and
readable)
ConradCarlen: still launched (deleting that)
ConradCarlen: gotta go - seems ok
DougTnscp: thanks man!!!
ConradCarlen: sure
I too suffer from this blocker bug under Mac OS 9.2.2 English North-American.
The last mac Mozilla 1.1a trunk full installer that installed a working version,
on my system, of Mozilla was posted on Friday 14th June. The versions of this
installer posted on June 15th and 16th install "normally", but when I attempt to
launch these versions of Mozilla it quits just a moment after the splash screen
first appears without any other incident being apparent.

As it takes me 45 minutes to download the full installer, & as the stub
installers rarely work fo me, I have not bothered to try later builds of this
installer.
can you check in your "Essential Files" folder for a file name that ends with .cfg.

Also, can you check in your Components directory for .dat files?  What are their
names, if any exists?
Without knowing this was going on here, I posted a similar problem the other
day.  In response to the questions Doug posed to wighta, I have no file in my
Essentials Folder ending in .cfg.  The following is a list of the files in my
Components folder.  HTH:

Len

Macintosh HD:Applications (Mac OS 9.2.2):Mozilla Folder:Components:
Tuesday, June 18, 2002  01:06:33 PM

appcomps.shlb
AppShell.shlb
bmpdecoder.shlb
browser.xpt
Cache.shlb
Caps.shlb
chardet.shlb
ChomeRegistry.shlb
Composer.shlb
content.shlb
Cookie.shlb
docshell.shlb
dom.shlb
EditorTxmgr.shlb
EmbedComponents.shlb
FindComponent.shlb
gfx2.shlb
gfxComponent.shlb
gifdecoder2.shlb
HTMLEditor.shlb
htmlparser.shlb
icondecoder.shlb
inspector.shlb
inspector.xpt
jpegdecoder2.shlb
jsconsole-clhandler.js
jsdService.shlb
JSLoader.shlb
jsurl.shlb
layout.shlb
libimg2.shlb
libjar.shlb
libpref.shlb
lwbrk.shlb
mngdecoder.shlb
Mork.shlb
mozBrowser.shlb
Necko.shlb
Necko2.shlb
nsCloseAllWindows.js
nsDictionary.js
nsDownloadProgressListener.js
nsHelperAppDlg.js
nslocale.shlb
nsProgressDialog.js
nsProxyAutoConfig.js
nsSidebar.js
nsXmlRpcClient.js
oji.shlb
PIPBOOT.shlb
PIPNSS.shlb
PIPPKI.shlb
plugin.shlb
pngdecoder2.shlb
prefextras.shlb
prefm.shlb
profile.shlb
RDFLibrary.shlb
RegViewer.shlb
shistory.shlb
strres.shlb
TextServices.shlb
transformiix.shlb
uconv.shlb
ucvcn.shlb
ucvibm.shlb
ucvja.shlb
ucvko.shlb
ucvlatin.shlb
ucvtw.shlb
ucvtw2.shlb
unicharutil.shlb
universalchardet.shlb
uriloader.shlb
venkman-service.js
view.shlb
Wallet.shlb
WalletViewers.shlb
widget.shlb
xbmdecoder.shlb
xfer.shlb
xmlextras.shlb
XPConnect.shlb
xpinstall.shlb
xpti.dat

Please try, delete "Component Registry" in installation folder
and launch Mozilla. It works for me.
Confirmed on 2002061708 and 2002061803 trunk builds with OS 9.2.2.
re: additional Comment # 17 from Doug T

The files & names you requested are  below:

Tuesday, June 18, 2002 - 11:29
Elapsed time: 00:00:00

Disk: “3__my_iMac” (663.0M used, 1384.9M free)
Folder: “3__my_iMac:Applications (Mac OS 9):Internet applications:Mozilla 1.0.0
ƒ:Essential Files”
Listing 0 subfolders, 19 files, 3.3M on disk

gfx.shlb, 34K, shlb
JavaScript.shlb, 447K, shlb
LDAPClient.shlb, 170K, shlb
libreg.shlb, 33K, shlb
libutil.shlb, 4K, shlb
LiveConnect.shlb, 91K, shlb
NSPR20.shlb, 188K, shlb
NSRuntime.shlb, 15K, shlb
NSS3.shlb, 350K, shlb
NSSckbi.shlb, 182K, shlb
NSStdLib.shlb, 221K, shlb
SMIME3.shlb, 108K, shlb
Softoken3.shlb, 386K, shlb
SSL3.shlb, 105K, shlb
WidgetSupport.shlb, 5K, shlb
xpcom.shlb, 877K, shlb
XPICleanup, 78K, APPL
xpistub.shlb, 8K, shlb
zlib.shlb, 43K, shlb

=========================================

the only file ending in ".dat" in my Components folder is : xpti.dat

[my currently installed version of Mozilla is 1.0.0 posted June 10th on mozilla.org]
deleting the installed component.reg and relaunching works.
 since we have a usable workaround, this is no longer a smoketest blocker.
Severity: blocker → critical
Keywords: smoketest
I'd be surprised if my changes to package-mac could have caused XPCOM
registration issues, but if someone wants to try backing them out, this should
do it...

Index: packages-mac
===================================================================
RCS file: /cvsroot/mozilla/xpinstall/packager/packages-mac,v
retrieving revision 1.173
diff -u -2 -r1.173 packages-mac
--- packages-mac	4 Jun 2002 08:48:12 -0000	1.173
+++ packages-mac	14 Jun 2002 20:48:10 -0000
@@ -253,5 +253,5 @@
 ; to prevent migration bugs
 viewer:defaults:pref:*
-viewer:defaults:autoconfig:*
+viewer:defaults:autoconfig:prefcalls.js
 viewer:res:arrow.gif
 viewer:res:loading-image.gif

Or better yet:
-viewer:defaults:autoconfig:*
+viewer:defaults:autoconfig:platform.js
+viewer:defaults:autoconfig:prefcalls.js

Which is effectively what the autoconfig:* is doing.
Severity: critical → blocker
this is a packaging issue caused by me.
I fixed the mac packaging to include the new component registry.  This should be
bug fix will be in tomorrow's nightly build.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 152331 has been marked as a duplicate of this bug. ***
verified...works with commercial mac os9 build 2002-06-19-03-trunk
Status: RESOLVED → VERIFIED
*** Bug 152331 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: