Closed Bug 64007 Opened 24 years ago Closed 24 years ago

Mozilla/Netscape hardcoded

Categories

(SeaMonkey :: Installer, defect)

x86
Windows NT
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: BenB, Assigned: ssu0262)

References

Details

Attachments

(5 files)

Reproduce: 1. Change the product name in makeall.pl 2. Install 3. Try to uninstall Actual result: Error. "3: Uninstall Log Folder not found" Expected result: Exactly the version which I start the uninstaller for is uninstalled. Additional Comments: This is because the reg keys for Mozilla and Netscape are hardcoded in the (Un)Installer. See <http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/windows/setup/extra.c#5385> and <http://lxr.mozilla.org/seamonkey/source/xpinstall/wizard/windows/uninstall/extra.c#1521>. These "variables" are then referenced in uninstall.it etc.. I hope, it's clear that "Mozilla" *must not* be hardcoded. What do we have the env. variables $ENV{WIZ_nameProduct} for? Note that the code looks like that (apart from the hardcoded Mozilla) the *last installed* version (as determined by SOFTWARE\Mozilla\Mozilla SeaMonkey\ CurrenntVersion" in the winreg) will be uninstalled, not the one passed via the /ua param. Practically however, it seems to work ("uninstaller.exe /ua foobar" uninstalls version foobar, no matter what CurrentVersion says). Simon, please fix this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 64006 has been marked as a duplicate of this bug. ***
Another consequence: The installer will suggest to overwrite an existing Mozilla installation.
I have a fix at hand that needs a little more testing and a sr=. It will remove the hard coded strings. Reassigning this to myself.
Assignee: slucy → ssu
Any idea of the kind of timescale? This is a show stopper on a package release. I'm willing to test.
ssu, that's cool! Please attach the patch ASAP (i.e. today, if possible).
I'm going to try for today. I'm trying to do my normal testing procedures on my patches, but there network is not cooperating today. Simon, I might just send you the patch for you to test. It has about 3 other fixes in addition to this one (it was hard to find people to sr= last week). The fix to this bug requires a few minor changes to the config.ini and uninstall.ini files.
Status: NEW → ASSIGNED
> I'm trying to do my normal testing procedures on my > patches, but there network is not cooperating today. Don't let that hold you back. There are several ways to fix this bug, some of them might not help us, so I'd like to know which one you chose. > Simon, I might just send you the patch for you to test. Please cc me <ben.bucksch@beonex.com>. > The fix to this bug requires a few minor changes to the config.ini and > uninstall.ini files. Expected :).
for mozilla only, apply the first 2 patches. The other two are nscp specific. These patches also contain fixes for bugs # 64105, 60149, and 60039.
ssu, fix approach looks good. I am still vary of the uninstallation. Opened bug 64109 for that. Simon, I'll attach a patch without the unrelated changes. Can you then please try that out?
additional patch revisions have been attached to bug 64105 only for minimizing duplication of attachments in bugzilla. Let me know if you guys are still running into problems (besides bug 64109 :) I'm already thinking about how to resolve that bug).
> (besides bug 64109 :) I'm already thinking about how to resolve that bug) That's very nice, but it's not a short-term requirement.
See bug 64105 for final patches, r=dveditz@netscape.com
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Fix seems to work (Uninstaller now fails for other reasons, probably rooted at our end).Thanks for the fast fix, ssu!
mozilla installer build 20010129
Status: RESOLVED → VERIFIED
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: