Closed Bug 406335 Opened 17 years ago Closed 15 years ago

Software Update for portable or secondary Firefox install overwrites primary install's registry settings

Categories

(Firefox :: Installer, defect, P2)

Product:
Firefox
Component:
Installer
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 3.6a1

People

(Reporter: bugzilla, Assigned: robert.strong.bugs)

References

Details

(Keywords: fixed1.9.1)

Attachments

(1 file)

patch rev1
4.26 KB, patch
jimm
: review+
beltzner
: approval1.9.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

When performing a software update within a secondary or portable installation of Firefox (Mozilla Firefox, Portable Edition), the update process will take over all the registry entries of the primary install.

Reproducible: Always

Steps to Reproduce:
1. Install Firefox on a PC and have it up to date
2. Install an older copy in addition to the primary copy or an older copy of Mozilla Firefox, Portable Edition
3. Update the secondary copy
Actual Results:  
All registry keys for the primary local install of Firefox are overwritten (shell open for html/gopher/ftp, default icon, etc)

Expected Results:  
The registry should be untouched

This bug was apparently introduced within the last few point releases of Firefox.  It did not use to be an issue when a copy of Firefox launcher with the -profile switch was updated.
This will probably be fixed by bug 417152.
(In reply to comment #1)
> This will probably be fixed by bug 417152.

Obviously that bug is unrelated, I must have meant to comment in another bug.

Perhaps not related.   Recently while working in FF portable received a notice of an update, so updated.  And the result was that all FF was gone from the portable.    The public computer I was using also had FF installed, although not running.
This is a nasty bug that sharply reduces the usability of Portable Firefox. I hope it will be fixed in the next "point" release.

Robert, anything which could be done here?
Version: unspecified → Trunk
I recall making a comment in another bug that I believe this is fixed on the trunk... someone testing it against trunk would be a good thing.
Can someone test using a nightly 3.0 and software update? Thanks
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0/
This seems to have been fixed in 3.0. I upgraded my copy of Portable Firefox 3.0.0 to 3.0.1 without the bug surfacing.
Thanks Mike! I'm going to leave this open for a bit to see if we can get an additional confirmation.
(In reply to comment #8)
Anti-confirmation: When I used auto-update to upgrade Firefox Portable from 3.0 to 3.0.1 I *did* see the problem.
Michael, if you set the portable version as the default browser this will occur during update since the version updating owns those registry keys. Could you verify that the install you are upgrading isn't set as the default prior to upgrading? Also, what specifically is the problem you see?
My local installation if Firefox is the default browser. Firefox Portable is set to not check whether or not it's the default. The specific symptom I notice is that the Internet link in my start menu (on Windows Vista) no longer works and I get a "program not found" error. If I launch Firefox via the program menu entry and try to set it as the default browser it claims that it already is. I've generally fixed the problem by launching IE and setting it as the default then launching the local install of Firefox again and changing it back.
That would be the start menu internet registry keys which is separate from the default browser keys. Does typing http://mozilla.org/ in the 'Start Search' or Start -> run dialog start the correct version of Firefox. If so which I believe is the case then I'll just need to make it so the start menu internet registry keys aren't updated in this scenario.
To test this out I reverted both local and portable installations to 3.0 and used auto-update to upgrade my portable installation. It might be worth noting that when prompted to restart I selected the "Not Now" button and ran FirefoxPortable.exe again. The auto-restart bypasses the portable launcher and uses the local profile. :(

Launching via a URL does run from the local installation although I've seen an intermittent error message:

    "Windows cannot find "http://mozilla.org'. Make sure you typed the name
     correctly, and then try again."

After a delay the local Firefox launches and displays the Add-ons window.

If my portable installation is accessible (i.e. the flash drive is still connected) launching Firefox via the "Internet" link launches the portable installation with the *local* profile. If the portable installation is not available, I get an "Application not found" error.
Product: Firefox → Toolkit
I can still reproduce this bug when upgrading Firefox Portable 3.0.1 to 3.0.4 via browser menu.
When I went from 3.1 alpha to 3.1 beta, I didn't experience this issue.  I'll report back after beta 2 is served.
I suspect the only registry keys still affected by this bug as of the release of 3.0 are the HKLM\Software\Clients\StartMenuInternet
Well my value for that registry entry is Firefox.exe

I'm now running 3.0.4 and 3.1beta2 without cross-contamination.  WFM.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Component: Application Update → Installer
Product: Toolkit → Firefox
QA Contact: application.update → installer
Attached patch patch rev1 — — Splinter Review 
Jim, I already added this code for Thunderbird to prevent taking over the Clients\ registry keys when updating a secondary installation. I also changed the registry write tests to be the same as I changed for Thunderbird and Sunbird... I believe SeaMonkey is also using the same reg write test. Thanks
Assignee: nobody → robert.bugzilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #360056 - Flags: review?(jmathies)
Note: I moved this over to the Firefox installer component because app update uses the uninstaller binary (helper.exe) to perform post update processing such as updating registry keys so this needs to be fixed in the installer code.
Blocks: 383441
Priority: -- → P2
Comment on attachment 360056 [details] [diff] [review]
patch rev1

looks good to me.
Attachment #360056 - Flags: review?(jmathies) → review+
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/7f923bdce3d5
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #360056 - Flags: approval1.9.1?
Comment on attachment 360056 [details] [diff] [review]
patch rev1

Drivers, I already added this code for Thunderbird to prevent taking over the
Clients\ registry keys when updating a secondary installation when I updated its installer a while ago and as such the methodology has been tested.
Hi All
I've reported to the folks over at Portable Apps that the status of this bug is fixed.
They still have an older page informing people not to use the automatic updater in FireFox Portable
http://portableapps.com/node/10338#comment-110709

"Firefox's updater has a bug where a portable or secondary install of Firefox will overwrite the locally installed Firefox's registry settings when version update is performed. It appears this bug was introduced within the last few point releases of Firefox 2.x. It's filed as Bug 406335 within Bugzilla. Please vote for this bug if you have a Bugzilla account"

Perhaps someone from here should inform them 'officially' 
I added a note about the status of fixed and a link to Mr Stroung's post here. to their forum page. Hope that this was okay.
(In reply to comment #24)

The question is around fixed vs FIXED.  Was this fixed in trunk?  In the 3.1 branch?  I'm guessing it's not fixed in 3.0.6, so the page and the warning stay up until it is fixed in the release version and most users have a fixed version's updater that won't have this issue.
Target Milestone: --- → Firefox 3.2a1
(In reply to comment #25)
> (In reply to comment #24)
> 
> The question is around fixed vs FIXED.  Was this fixed in trunk?
Yes

> In the 3.1 branch?
I've requested approval for landing this for 3.1 and mentioned to one of the drivers that we should take this for 3.1

> I'm guessing it's not fixed in 3.0.6, so the page and the warning stay
> up until it is fixed in the release version and most users have a fixed
> version's updater that won't have this issue.
It hasn't landed for 3.0.6 and I'm not sure if this patch should be backported for 3.0.x

btw: Status Resolved -> Fixed or Verified is for the trunk unless the bug doesn't affect the trunk in which case it applies to the latest branch with the caveat that when we branch we use Keywords to denote where the bug is fixed. If this lands for Firefox 3.1 a keyword of fixed1.9.1 or verified1.9.1 (if someone verifies it is fixed) will be added and if this lands for Firefox 3.0.x a keyword of fixed1.9.0.x or verified1.9.0.x (if someone verifies it is fixed) will be added.
Attachment #360056 - Flags: approval1.9.1? → approval1.9.1+
To verify...

1. Download a build with this fix that can be updated via app update.
2. Install it to "c:\program files\mozilla firefox1\"
3. Install it a second time to "c:\program files\mozilla firefox2\"
4. Run "c:\program files\mozilla firefox2\firefox.exe" and set it as the default browser.
5. Run "c:\program files\mozilla firefox1\firefox.exe" and perform an app update.
6. Check that the registry keys still under
   HKLM\Software\Clients\StartMenuInternet\FIREFOX.EXE
   still point to the "c:\program files\mozilla firefox2\" install location

For extra credit check that the following registry keys under HKCR still point to "c:\program files\mozilla firefox2\"
FirefoxHTML
FirefoxURL
http
https
ftp
John, you can also remove the uninstall.log to prevent software update from updating any registry keys. This was added to support not updating registry keys for zip builds.
(In reply to comment #31)
> John, you can also remove the uninstall.log to prevent software update from
> updating any registry keys. This was added to support not updating registry
> keys for zip builds.

We don't have uninstall.log in any of our current builds and haven't for a while.
John, this would mean that you haven't had this issue for quite some time or do some people run the installer against portable Firefox?

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/installer/windows/nsis/common.nsh#4697

We don't perform any operations on the registry, etc. if there is no uninstall.log and haven't for quite some time.
(In reply to comment #33)

It would seem you're right.  Guess I hadn't noticed that.  I just tried to 3.0.5 to 3.0.6 upgrade on a clean XP box and it didn't mess with the local stuff.  I'll do some more verifcation to ensure it's the same on 2K and Vista and then update the public notes.  Thanks.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: