Closed Bug 789743 Opened 12 years ago Closed 12 years ago

FF 15.0 to 15.0.1 Internal Update adds extra Uninstall Entry in Windows 7 Programs and Features

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
15 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla18
Tracking Flags:
Tracking Status
firefox15 - wontfix
firefox16 + verified
firefox17 --- verified
firefox18 --- verified

People

(Reporter: bugzilla, Assigned: bbondy)

References

Details

(Keywords: regression, verifyme)

Attachments

(2 files, 1 obsolete file)

Patch v2.
3.81 KB, patch
bbondy
: review+
akeybl
: approval-mozilla-aurora+
akeybl
: approval-mozilla-beta+
Details | Diff | Splinter Review
FF15.0 still listed with FF16
7.61 KB, image/png
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

Updated Firefox 15.0 to 15.0.1 using the internal updater via Help > About Firefox.


Actual results:

I looked at Windows 7 Pro 64bit's Programs and Features list and notice an entry for Firefox 15.0 and Firefox 15.0.1. I went searching in the registry and found the following:

FF 15.0.1 Uninstall information was stored here:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox 15.0.1 (x86 en-US)

FF 15.0 Uninstall information was stored here:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Mozilla Firefox 15.0 (x86 en-US)

Wonder if it's related to the Mozilla Maintenance Service thing. Almost like FF 15.0.1 was handled like a User only install.

Following is a MozillaZine topic about it: http://forums.mozillazine.org/viewtopic.php?f=38&t=2538425


Expected results:

It should have replaced the original registry entry such that only a single item is listed in the Programs and Features list of Windows 7.
Component: Untriaged → Application Update
Keywords: qawanted
Product: Firefox → Toolkit
Just thought I'd confirm I've encountered the same issue in Windows 8 Release Preview x64 and Windows 7 x86. The registry situation is the same in 8, can't check 7 anymore since I uninstalled both entries and reinstalled via manual download.

My Firefox on Win8 updated itself in the background with no manual update check, if that helps rule anything out.

Uninstall entries for Firefox Beta and Aurora have also moved to the current user registry branch (Aurora has left behind a duplicate, Beta was on 15.0 so the entry was overwritten when stable updated to 15.0). SeaMonkey stable/beta/aurora has remained in the local machine WoW64 branch, supporting the theory that the new maintenance service has started doing something different (at least, SeaMonkey doesn't appear to use the service).
Will and Mark, would you mind to check what happens when you upgrade from Firefox 14.0.1 to Firefox 15.0.1? Does it also happen in such a case?
Keywords: regression, regressionwindow-wanted
I've just completed a few experiments on the Windows 7 x86 machine I mentioned above whilst observing the registry for uninstall entries.

- 15.0.1 clean install: normal
- 14.0.1 clean install -> 15.0.1 about-box update: normal
- 14.0.1 clean install -> 15.0.1 installer update: normal
- 14.0.1 clean install -> 15.0 installer update -> 15.0.1 about-box update: duplicate
- 14.0.1 clean install -> 15.0 installer update -> 15.0.1 installer update: normal (but I was forced to reboot the computer after the 15.0.1 update on both occasions that I attempted this particular update sequence)

The "normal" results in all cases mean that at the end a single uninstall entry for Firefox was present in the local machine branch of the registry (alongside the entry for the maintenance service). The "duplicate" result is the one originally reported, an entry for 15.0 remains in the normal local machine branch and a new entry for 15.0.1 appears in the current user branch.
I don't know if it's any help but of those two uninstall entries, one triggered an UAC prompt, while the other brought up the uninstaller without a prompt.
Here's some other info. The 15.0.1 Upgrade I did also added all this to the registry:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Mozilla]

[HKEY_CURRENT_USER\Software\Mozilla\Firefox]

[HKEY_CURRENT_USER\Software\Mozilla\Firefox\Crash Reporter]
"Email"=""
"IncludeURL"=dword:00000001
"EmailMe"=dword:00000000
"SubmitCrashReport"=dword:00000001

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox]
@="15.0.1"
"CurrentVersion"="15.0.1 (en-US)"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox\15.0.1 (en-US)]
@="15.0.1 (en-US)"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox\15.0.1 (en-US)\Main]
"Install Directory"="C:\\Program Files (x86)\\Mozilla Firefox"
"PathToExe"="C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox\15.0.1 (en-US)\Uninstall]
"Description"="Mozilla Firefox 15.0.1 (x86 en-US)"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox 15.0.1]
"GeckoVer"="15.0.1"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox 15.0.1\bin]
"PathToExe"="C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe"

[HKEY_CURRENT_USER\Software\Mozilla\Mozilla Firefox 15.0.1\extensions]
"Components"="C:\\Program Files (x86)\\Mozilla Firefox\\components"
"Plugins"="C:\\Program Files (x86)\\Mozilla Firefox\\plugins"


The Firefox 15.0 counterpart is still here:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox]

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\Extensions]
"{22119944-ED35-4ab1-910B-E619EA06A115}"="C:\\Program Files (x86)\\Siber Systems\\AI RoboForm\\Firefox"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Firefox\TaskBarIDs]
"C:\\Program Files (x86)\\Mozilla Firefox"="E7CF176E110C211B"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox]
@="15.0"
"CurrentVersion"="15.0 (en-US)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\15.0 (en-US)]
@="15.0 (en-US)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\15.0 (en-US)\Main]
"Install Directory"="C:\\Program Files (x86)\\Mozilla Firefox"
"PathToExe"="C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox\15.0 (en-US)\Uninstall]
"Description"="Mozilla Firefox 15.0 (x86 en-US)"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox 15.0]
"GeckoVer"="15.0"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox 15.0\bin]
"PathToExe"="C:\\Program Files (x86)\\Mozilla Firefox\\firefox.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Mozilla\Mozilla Firefox 15.0\extensions]
"Components"="C:\\Program Files (x86)\\Mozilla Firefox\\components"
"Plugins"="C:\\Program Files (x86)\\Mozilla Firefox\\plugins"

So, there's more than just the Uninstall key that's duplicated/added to the Current User tree. I haven't tried various install/upgrade methods to see how the registry entries compare yet. Sort of curious what happens with the next upgrade if I just left it as is.
(In reply to Will Elwood (:Will) from comment #3)
> - 14.0.1 clean install -> 15.0 installer update -> 15.0.1 about-box update:
> duplicate

So can you just replicate this by installing 15.0 and updating through the about window? Means without having to install 14.0.1 first.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Henrik Skupin (:whimboo) from comment #6)
> So can you just replicate this by installing 15.0 and updating through the
> about window? Means without having to install 14.0.1 first.

I have done this and the result is the same: FF 15.0 and FF 15.0.1 are both listed.
Those are the changes between 15.0 and 15.0.1:
http://hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=450143d2d810&tochange=0b774a1067fe

None of them have anything to do with the updater. So I wonder why that happens for 15.0->15.0.1. 

Could anyone please try if this is reproducible when upgrading 16.0b1 to 16.0b2? the 16.0b1 builds can be found here:

ftp://ftp.mozilla.org/pub/firefox/releases/16.0b1/
tracking-firefox15: --- → ?
> None of them have anything to do with the updater. So I wonder why that happens for 15.0->15.0.1.
14.0 -> 15.0 update will be performed by 14.0 updater.
15.0 -> 15.0.1 update will be performed by 15.0 updater.
So changes between 14.0 and 15.0 would have the regression.
Oh, right. Good catch! So here the updated pushlog (it will take a long time to load!):

hg.mozilla.org/releases/mozilla-release/pushloghtml?fromchange=e5728a4e106c&tochange=450143d2d810

So could someone please test individual 15.0 beta releases so that we can figure out which of those shows the issue first?
tracking-firefox16: --- → ?
(In reply to Henrik Skupin (:whimboo) from comment #9)
> 
> Could anyone please try if this is reproducible when upgrading 16.0b1 to
> 16.0b2? the 16.0b1 builds can be found here:
> 
> ftp://ftp.mozilla.org/pub/firefox/releases/16.0b1/

I did (removed 15 and double listing also first) and there is no double listing now, however: FF 16.0b1 and FF 16.0b2 have the same name in the Windows 7 Programs and Features list: Mozilla Firefox 16.0 (FF15 has different entry names: 15.0 vs 15.0.1)
tracking-firefox16: ? → ---
(In reply to Henrik Skupin (:whimboo) from comment #11)

> So could someone please test individual 15.0 beta releases so that we can
> figure out which of those shows the issue first?

Beta-versions have the same name in the Win7 "Program list", maybe that's why the bug didn't show up?
So I think that this issue is related to the background updates implemented on bug 307181 for Firefox 15. CC'ing Ehsan who mostly did all the work. He probably knows better which of the patches could have caused it. 

But given the helpful information from Mark on comment 5, it really looks like a dupe of bug 773077 now.
Flags: in-testsuite?
I am seeing the following in my "Uninstall or change a program" control panel in Windows 7 Professional 64 bit (Microsoft Windows Version 6.1 (Build 7601: Service Pack 1):


Aurora 16.0a2
Aurora 17.0a2

Also "Mozilla Maintenance Service" (What the heck is this one?).
Brian, do you have time to investigate this?
(In reply to Ehsan Akhgari [:ehsan] from comment #16)
> Brian, do you have time to investigate this?

Not really, as we have a Metro preview due at the end of this month and I'll be reviewing the stub installer once it's ready.  But I may have to if no one else picks it up:)

Worcester12345 have you installed 2 versions of Aurora in the past? 
The Mozilla Maintenance Service is normal and is for silent updates without a UAC prompt.  It is an optional component.
Here's some more information. I uninstalled FF 15.0 (kept my settings) and then made sure the extra registry entries were gone. I then installed 15.0 again along with Maintenance Service.  I then went into Tools > Options > Advanced > Update and unchecked the option to "Use a background service to install updates". 

I then went into Help > About Firefox and clicked the "Check for Updates" button. It found and transferred 15.0.1 and this time it prompted me with the UAC prompt asking permission and I granted it. This time I only have FF 15.0.1 listed in Programs. Other than the Crash Reporter part, everything is in HKLM now.

I do have Thunderbird 15.0.1 installed as well.. so some of the generic Mozilla entries could be from it.

So, this tells me it is definitely related to the update being performed by the Maintenance Service that suppresses the UAC prompt. Of course, changing entries in HKCU doesn't require the elevations that HKLM would.
If anyone has time it would be helpful to know if this bug reproduces when app.update.stage.enabled is set to false.
This can be set in about:config by the way.
(In reply to Brian R. Bondy [:bbondy] from comment #19)
> If anyone has time it would be helpful to know if this bug reproduces when
> app.update.stage.enabled is set to false.

Not reproducible by updating this way, now only FF 15.0.1 is listed.
Thanks for the info, this helps narrow down the issue considerably.
Blocks: bgupdates
Assignee: nobody → netzen
(In reply to Brian R. Bondy [:bbondy] from comment #19)
> If anyone has time it would be helpful to know if this bug reproduces when
> app.update.stage.enabled is set to false.

FYI, when I did my update with the maintenance service disabled, this value was set to true and still is. My guess is app.update.service.enabled (set to false now) controls the Maintenance Service option.
Thanks for the info MarkRH.  When the maintenance service is disabled it also disables background updates, so that's why you didn't see the issue with the service turned off.  In Comment 21 Coyote kept the service on but background updates off and Coyote could not reproduce the problem in that way.
It doesn't sound like this will warrant a new FF15 release, but we should track for including a fix in FF16.
tracking-firefox15: ? → -
tracking-firefox16: --- → +
So to understand what the issue is....

For service updates we call PostUpdate from:
1) current user unelevated to get the HKCU user specific entries
2) the system account elevated to get the HKLM entries

When the update is not a bgupdate, there is no problem
When theupdate is a bgupdate the second call fails, leaving the last entries.

I noticed this in the log:
Launching post update process as the service in session 0.
***The post update process could not be launched.***

I haven't found the reason yet for why it can't be launched, but probably the path to helper.exe is being passed in wrong or something like that.
Attached patch Patch v1. (obsolete) — — Splinter Review 
So the problem is that it's not executing the PostUpdate process when elevated, hence leaving the old uninstall entries. The reason it's not executing it is because it's trying to find helper.exe inside the /updated directory, but that is already moved out at this point. 

This error did show up in the logs of all channels btw, we just didn't notice it :(
Attachment #660288 - Flags: review?(ehsan)
Keywords: regressionwindow-wanted
I didn't test this yet btw, but I'll test on oak before pushing. I re-checked out oak for updater work since we have a few different updater tasks left (x64, limited user accounts, regressions, ...)
Depends on: 790496
Comment on attachment 660288 [details] [diff] [review]
Patch v1.

Review of attachment 660288 [details] [diff] [review]:
-----------------------------------------------------------------

ouch!
Attachment #660288 - Flags: review?(ehsan) → review+
Attached patch Patch v2. — — Splinter Review 
Noticed a missing comma, carrying forward r+
Attachment #660288 - Attachment is obsolete: true
Attachment #660299 - Flags: review+
Brian, is bug 773077 a dupe of this bug now? Or do we not fix the right registry keys usage with your patch?
It looks like it's a dupe of bug 773077.  But we wrongly attributed that bug to bug 773077 Comment 13.  Since the patch is here already I'll mark that bug a dupe of this one.
Assigning Juan as the QA contact for this bug. I want to make sure that we not only verify the fix, but also verify that the extra entry is removed.
QA Contact: jbecerra
Sounds good, the fix should work for removing already affected users and ensure that future people won't be affected.
Depends on: 790467
Just wanted to mention that I don't feel comfortable landing this without testing it on Oak.  I've been trying to get Oak setup since Sept 11 but it is still pending. I would hate to see this not make beta, but it may come to that.
The Oak setup bug is here: bug 790467
Comment on attachment 660299 [details] [diff] [review]
Patch v2.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 307181 
User impact if declined: Users will have 2 uninstall entries with different versions, uninstalling either will uninstall Firefox.
Testing completed (on m-c, etc.): Tested silent updates with background updates and without on oak.  Both worked. Oak is a clone of m-c.  Landing directly on m-c now. 
Risk to taking this patch (and alternatives if risky): Low since testing was done
String or UUID changes made by this patch: none
Attachment #660299 - Flags: approval-mozilla-beta?
Attachment #660299 - Flags: approval-mozilla-aurora?
http://hg.mozilla.org/mozilla-central/rev/abada9261f82
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox18: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Since this is now fixed, swapping the qawanted keyword for verifyme to flag for verification.
Keywords: qawanted → verifyme
Comment on attachment 660299 [details] [diff] [review]
Patch v2.

[Triage Comment]
We believe this is a low risk fix for a top SUMO issue. Approving for Aurora/Beta uplift.
Attachment #660299 - Flags: approval-mozilla-beta?
Attachment #660299 - Flags: approval-mozilla-beta+
Attachment #660299 - Flags: approval-mozilla-aurora?
Attachment #660299 - Flags: approval-mozilla-aurora+
I can reproduce this easily with Fx15.0 - 15.0.1, but I can't reproduce this with a nightly, beta or aurora prior to the fix having tried manual check for updates and also by waiting for it to download and apply in the background.

Let me know if there's another way to test this.
I tested this by checking the c:\programdata\mozilla\logs, before they contained an error message as in comment 26.  A better way to test though would be to modify the HKLM and HKCU registry uninstall keys so that they differ.  Once they differ it will show 2 uninstall entries in your control panel.

Example location if you're on x64:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Nightly
(Your location may differ).

You also need an equivalent HKCU entry.  The way to get both of them is to have an update occur through the service. 

After you have both entries you can reinstall the previous browser and update again. It should update both HKCU and HKLM registry locations.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0

Verified by updating from Firefox 16 beta 5 to Firefox 16 beta 6 that the maintenanceservice.log does not contain the error message from Comment 26. 

"Launching post update process as the service in session 0.
updater.exe was launched and run successfully!"
Unfortunally FF15.0 still listed (with FF16); FF15.0.1 not listed.
Sorry for double post, This is what I mean.
The fix landed for Firefox 16's release. I would expect that this will appear fixed with the first Firefox 16 update (ie. Firefox 17). In other words, when Firefox 16 updates to Firefox 17 in 6 weeks you will just have Firefox 17 in the Programs list. You might have to manually remove the Firefox 15 entry given that this is wontfix for Firefox 15.

Brian, please correct me if I am wrong.
I think the problem that was suspected to have caused this was a fix in PostUpdate, which should run with the new code.  I'll re-open for now to investigate further.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Actually the problem was that PostUpdate wasn't running, but the place that executed the PostUpdate operation was inside the service, which would have been running old code.

So Anthony is correct that the next update should fix this.

It would be good for QA to verify though by manually staging the registry settings mentioned in bug 799568 to see if an update with the new service fixes it.

If we end up doing a chem spill it will also auto get fixed at that point.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Updated to FF 16.0.1 (from 16.0) and everything is fine now. This also is the case for Thunderbird: the error never occured there.
Thanks Coyote.
status-firefox16: fixed → verified
I am seeing this having just updated from 15 to 16.0.1. In control panel -> uninstall, firefox 15 is still listed along side 16.0.1; the registry contains the uninstall information for 16.0.1 under HKEY_CURRENT_USER rather than HKEY_LOCAL_MACHINE.
(In reply to sam morris from comment #54)
> I am seeing this having just updated from 15 to 16.0.1. In control panel ->
> uninstall, firefox 15 is still listed along side 16.0.1; the registry
> contains the uninstall information for 16.0.1 under HKEY_CURRENT_USER rather
> than HKEY_LOCAL_MACHINE.

Updating from 15 (to 16.0.1) occurs with the FF 15-updater. The bug was present in FF 15. The next update will happen with the FF 16-updater, the extra entry will remove itself during the update process.

What I did was updating from 15 to 16 and then again to 16.0.1. So the last update was with the FF 16-updater.
Got it. Sorry for the confusion.
Based on Comment 52 marking this as verified.
Status: RESOLVED → VERIFIED
Marking this back as Resolved since Verified is usually checked on the m-c branch.
Status: VERIFIED → RESOLVED
Closed: 12 years ago → 12 years ago
(In reply to Brian R. Bondy [:bbondy] from comment #58)
> Marking this back as Resolved since Verified is usually checked on the m-c
> branch.

.... err all branches that it lands on.
Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Firefox/17.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0

Verified that no extra Uninstall Entry is left after updating to Firefox 17 (in Windows 7 Programs and Features).

Verified by updating from:
- Firefox 17 beta 3 to Firefox 17 beta 6 - there is no error in the maintenanceservice.log as the one mentioned in Comment 26.
- Firefox 16.0.2 to Firefox 17 - there is no error in the maintenanceservice.log and no extra Uninstall entry in the Programs and Features list in Control Panel.

Verified as fixed on Windows 7 32-bit and Windows 7 64-bit.
Updating FF 18b4 to FF 18b5 works as expected. Based on this and on Comment 53 and Comment 60 I consider this issue Verified Fixed.
Status: RESOLVED → VERIFIED
status-firefox18: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: