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

RESOLVED FIXED in Firefox 3.6a1

Status

()

Firefox
Installer
P2
major
RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: John T. Haller (email is bugzilla2@), Assigned: rstrong)

Tracking

({fixed1.9.1})

Trunk
Firefox 3.6a1
x86
Windows XP
fixed1.9.1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
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.

Comment 3

10 years ago
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.

Comment 4

10 years ago
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/

Comment 8

10 years ago
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.

Comment 10

10 years ago
(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?

Comment 12

10 years ago
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.

Comment 14

10 years ago
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

Comment 15

9 years ago
I can still reproduce this bug when upgrading Firefox Portable 3.0.1 to 3.0.4 via browser menu.

Comment 16

9 years ago
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

Comment 18

9 years ago
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
Created attachment 360056 [details] [diff] [review]
patch rev1

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.

Updated

9 years ago
Blocks: 383441
Priority: -- → P2

Comment 21

9 years ago
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
Last Resolved: 9 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.

Comment 24

9 years ago
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.

Updated

9 years ago
Target Milestone: --- → Firefox 3.2a1

Updated

9 years ago
Duplicate of this bug: 467789
(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+
Pushed to mozilla-1.9.1 for Firefox 3.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1439f3ec8d35
Keywords: fixed1.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.