64109 - Only last installed build of a given version/milestone can be uninstalled

Status: RESOLVED INCOMPLETE

(SeaMonkey :: Installer, enhancement)

Description

[Ben Bucksch (:BenB)]

Reproduction:
- Install 2 different versions of Mozilla in different dirs, older one first.
- Uninstall the older one

Expected:
Only the older one goes.

Actually (suspected, if I read the code correctly):
The newer one is uninstalled.

See also bug 64007.

Comment 1

[Ben Bucksch (:BenB)]

We need to check this. If I'm right, this is a critical problem.

Comment 2

[Sean Su]

This is actually "as designed".  As far as I'm aware, we don't really support
installation of the same product into multiple different places.  What I mean by
"don't really support" is that developers can have multiple copies of mozilla on
the same system, but the OS might not see it as that.

Under windows, take for instance the fact that MS requires each app to register
in the following windows registry key:
  key:  HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\app
paths\[main app name - in this case mozilla.exe]
  name: {default value}
  value: [absolute path to mozilla.exe including filename]
  name: Path
  value: [paths to be used by mozilla.exe to search for dlls or other files]

Also, the Uninstaller was not designed to uninstall multiple "same" versions of
a product.  "Same versions" being 0.7, 0.8, 0.9, 1.0, and so on...  This was not
part of the spec.

Why would this be a critical problem?  Will end users install multiple copies of
mozilla?  For people wanting to "brand" their version of mozilla, this should
not be a problem (wrt) the uninstaller as long as the Product name is different,
(unless this is the problem).

Comment 3

[Ben Bucksch (:BenB)]

> This is actually "as designed".

Severity enhancement.

> Why would this be a critical problem?

It would be a critical problem, if there an entries for each version in the
Software dialog, and the user spcifically chose one version.

> Will end users install multiple copies of mozilla?

Well, end users should not install Mozilla at all, by definition. As for Beonex,
this is thinkable, yes. E.g. we might support 2 different version at the same
time - one more tested, the other one newer with more features or faster or
whatever. Much like what Netscape does with 4.x vs. 6 at the moment.

Comment 4

[Ben Bucksch (:BenB)]

What do you mean with "same versions"? How would that look like at Mozilla 2.0
times? I hope, you won't add a version number to the product anme itself (in
addition to the normal version number). There won't be a Mozilla2 1.0 or similar.

Comment 5

[Henrik Gemal]

Also remember bug 46018...
"Uninstall entry should not contain version number"

Comment 6

[Ben Bucksch (:BenB)]

My idea was to just replace

Main Key=[Product WinRegKey]
Key=[Product CurrentVersion]\Uninstall

with

Main Key=Software\$CompanyName$\$ProductName$\$UserAgent$
Key=Software\$CompanyName$\$ProductName$\$UserAgent$\Uninstall

but it didn't work right away and I didn't debug it. Any reasons why this
wouldn't work? Are there other problems to consider?

Comment 7

[Sean Su]

It doesn't work because there's only one copy of the uninstaller for a given
product.  For mozilla, it's [windir]\MozillaUninstaller.exe.  This means that
the last installed version of mozilla is the one that will be uninstalled.

Dan did suggest that the uninstaller live within each products' folder, like
[Program Files]\Mozilla\Seamonkey\MozillaUninstaller.exe

But that will prevent [Program Files]\Mozilla\Seamonkey folder from being
removed at a system reboot (Windows' delete at startup routine does not remove
folders), not that it does now anyways due to files being created there after
installation.

Also having each uninstaller instance live in each new installation folder will
not work until the uninstalling process is redone to register each one uniquely
in the Add/Remove Program Files control panel.

Comment 8

[Ben Bucksch (:BenB)]

Is it really only the invokation of the right uninstaller, which is the problem?
As for the filename, you could add the (complete) version number to the
filename. Similar for the registration under SOFTWARE\...\Windows\...\Uninstall\.

Comment 9

[Daniel Veditz [:dveditz]]

Need preliminary nsbeta1 look to see if we're worried about 6.0 upgraders

Comment 10

[Daniel Veditz [:dveditz]]

Moz 0.9 tasks

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

Take a look at AOL's uninstaller program.  It searches it's default install
locations and says something similar to "You have 3 copies of AOL installed. 
Select the version(s) that you wish to remove."  And has a list of all installed
versions of AOL.  You can choose to remove one, none, or multiple versions all
at once.

Comment 12

[Christopher Aillon (sabbatical, not receiving bugmail)]

Scenario: end user downloads latest milestone release.  Finds a bug and reports
it here.  We ask them to get a newer nightly build and see if the problem still
occurs.  Since the nightlies "will probably work, but maybe not" (per mozilla
home page) they decide they want it in a new directory because just to be safe.
 They test the newer nightly and the bug is fixed in it so they decide to
uninstall old version and click the uninstaller....

Comment 13

[Sean Su]

over to Curt.

Comment 14

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7b) Gecko/20040421] (<-- 1.7rc1 !)
(W98SE)

See bug 240738 comment 9.
{{{
"GRE core" is fully identified: with full build "date"
{{
[HKEY_LOCAL_MACHINE\Software\mozilla.org\GRE\1.7_2004051408]
}}

Whereas "Mozilla app" is partially identified: release number only
{{
[HKEY_LOCAL_MACHINE\Software\mozilla.org\Mozilla\1.7 (en)]

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla
(1.7)]
"DisplayName"="Mozilla (1.7)"
"UninstallString"="X:\\WINDOWS\\MozillaUninstall.exe /ua \"1.7 (en)\""
}}
}}}

In other words: (for example)
v1.7a (Alpha), v1.7b (Beta), v1.7 (Final) milestones can be (un)installed
without trouble;
but release candidates can't, as being all identified as v1.7, and not v1.7rc_.

I guess it's the same about nightlies, but this would have to be checked.

I'm using 2 milestones at the same time, as in comment 12, to check possible
regressions.

Comment 11 suggestion seems very interesting;

In the meantime, detecting the conflict, and possibly letting the user choose to
proceed or quit, would be fine.
This could be a matter of checking that the windows registry keys already exist !?

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

old XPFE installer is dead.

Comment 22

[Serge Gautherie (:sgautherie)]

(In reply to comment #21)

It is.
But did you check how the new SM 2.0 installer behaves?