Open Bug 1414833 Opened 7 years ago Updated 2 years ago

Release version is being upgraded to beta instead of being installed in two different locations

Categories

(Firefox :: Installer, defect, P3)

All
Windows
defect

Tracking

()

Tracking Status
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- affected

People

(Reporter: obotisan, Unassigned)

References

Details

[Affected versions]:
- beta 56.0b2
- beta 57.0b14
- RC 56.0

[Affected platforms]:
- Windows 10 x64
- Windows 8.1 x32

[Steps to reproduce]:
1. Install Firefox 56.0
2. Install beta 57.0b14
3. Observe behaviour.

[Expected result]:
- There are two different folders created in Program Files and two versions of Firefox installed in the computer.

[Actual result]:
- There is only one folder created and beta instead of being installed, upgrades the version already installed in the computer.

[Regression range]:
- I am not sure I can find a regression range. 

[Additional notes]:
- It would be better if there are two folders created, one for RC and one for beta.
- It doesn't matter if the first version installed is newer than the second version, the program is still being "upgraded" to the second version.
We can't distinguish RC from release in the installer, but we could perhaps distinguish release from beta.

Currently, beta uses the same branding files as release, and both the install directory and the registry keys we look in to find existing installations are just named after the product branding name, so beta and release think that they are the same thing.

Previously we've made the assumption that users needing to have both a beta and a release installed were fairly advanced and would set custom install paths that fit what they needed, but perhaps we should reexamine that idea now that the stub installer no longer offers that setting.

But all we could really do is tack 'Beta' onto the end of the install path, but even that might get complicated; we'd have to get that full string localized, as 'Mozilla Firefox Beta' might not always make sense, and we'd have to make sure whatever we do doesn't update existing installations (and as bug 1413295 is currently demonstrating, renaming things without pulling the rug out from under either the installer or Windows can be really really hard).

In the meantime, the workaround is to download full installers and use those to set custom installation paths.

Maybe this should be marked as a duplicate? I'm not entirely sure, so I'm just going to link it for now.

See Also: → 1554027
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.