mozilla 1.4a crash after upgrade from 1.3b



16 years ago
15 years ago


(Reporter: matp75zilla, Assigned: asa)


Windows 2000

Firefox Tracking Flags

(Not tracked)





16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401

Mozilla 1.4a (complete install with talback enabled) crash at startup after
message is application error, an error log will be generated.
same crash when I :
- upgrade directly from 1.3b to 1.4a 
- remove 1.3b with add remove/program and install 1.4a
- remove 1.4a and reinstall 1.4a

the crash happens every time

By removing the mozilla directory in program files, I can succesfully install 1.4a

Reproducible: Always

Steps to Reproduce:

Expected Results:  
Upgrade should just run successfully without having to remove files manually.
I should have had a talbalk report at least but only had a crash

I had flash 6, java and acrobat plugins installed and mozilla calendar for 1.3b
there were some files left which seems mostly calendar related
I will attach the files to this bug

Comment 2

16 years ago
reporter, please read the release notes
[] which say "Install into a new
empty directory. Installing on top of previously installed builds may cause

Also : search bugzilla before filing a new bug.

Read bug 195600 for further comments as to the cause of this problem

*** This bug has been marked as a duplicate of 195600 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 3

16 years ago
I looked at the mostfreq bugs and did a search on crash and 1.4a and calendar
and 1.4a. this is why I didn't find bug 195600
I don't agree that I should have to remove manually files with every mozilla
It should at least work if I deinstall the program, which is what I did.
I have no way to deinstall the calendar xpi and mozilla installer doesn't ask to
desinstall it or warn about possible conflict when installing.
As I have downloaded a talkback enabled build, it should have run the talback
reporter, not just crash !
If some version of calendar xpi is known to be incompatible with 1.4a, the
installer should warn about this

Comment 4

16 years ago
I see your point...... but ;-)....
Typically you can install Mozilla on top of older version. Sometimes however,
new features are implemented that break backwards compatibility. In that case
you have to uninstall Mozilla to get things to work. 

The mozilla uninstaller, uninstalls Mozilla. And only that. 

If you install add-ons like spell check, enigmail, Calendar etc. they will (a)
not be uinstalled and (b) not be compatible with your new Mozilla. 
[Please note that this behavior is by design because no program should unistall
items that it didn't install].

These add-ons do not have an uninstaller and their presence brings down Moz. To
uninstall these add-ons you have to manually delete them [clear out the Moz folder].

Bug 195600 comment 2 also talks about an RFE for checking target folder before
installation. As far as i know, no such rfe has been filed yet.

This bug, as it is phrased, is still a duplicate of 195600 as it describes a
Mozilla crash after an installation not according the installation notes.

If you file an rfe for checking the target folder before installation you can
refer to this bug and bug 195600. Also it would be appreciated if you report the
bug number for that rfe under bug 195600.

Comment 5

16 years ago
correction : make that "bug 195600 comment 6"

Comment 6

16 years ago
just opened an rfe about adding a warning if destination directory is not empty.
Please see bug 200651

Comment 7

16 years ago
My RFE mentioned in bug 195600 comment 6 was indeed filed. It is bug 195818. 

Bug 195818 comment 1 notes that several unclean install issues block doing this
with certainty, and the commenter added these issues as blockers.

Given all that, and the valid statement in comment 4 that the Moz uninstaller
shouldn't uninstall stuff that it didn't install, I would say this RFE should
technically be marked as a duplicate or blocker of bug 195818 instead of bug
195600. But it doesn't seem worth the trouble.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.