1201734 - FF update 40.0.3 to 41.0 adds extra Uninstall Entry in Win10 Programs and Features

Status: NEW

(Firefox :: Installer, defect, P3)

Description

[Onno]

Attachment: Double FF 40 entry.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150826023504

Steps to reproduce:

FF updated to 40.0.3 from 40.0.2


Actual results:

After that old entry of 40.0.2 is still listed also in the programs and Features list of Win10


Expected results:

Only 40.0.3 should have been listed

Comment 1

[[:Towkir] Ahmed]

did you try disabling your add-ons ????
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 2

[Onno]

No, but I also don't see the benefit of trying that. There are no problems with Firefox running. It runs as it should. I only found out that there are 2 instances of FF are "installed" in Win10: 40.0.2 and 40.0.3. Running in safe mode will not solve the problem of a "double installation".

I updated as usual and before that I didn't see any double instances of FF installed. Maybe something to do with Win10? That is new...

Comment 3

[Onno]

I tried now using safe mode, but no difference.

Comment 4

[Onno]

Help --> about in FF says I have version 40.0.3. So the old instance was simply not removed during the update process.

Comment 5

[Onno]

This happened again, now from 40.0.3 to FF 41.0. The two entries (old and new) in the program list in Win10 are there.

Comment 6

[Molly Howell (she/her) (no longer active)]

Can you check something out for us? Do the following steps:

1) Open your Start menu
2) Type in "regedit" and press Return
3) In the tree view on the left hand side of the window that appears, expand out this path:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\

4) Post a comment here letting us know whether you have either of the two following entries in that location:

Mozilla Firefox 40.0.2 (x86 nl)
Mozilla Firefox 40.0.3 (x86 nl)

5) Repeat step 3 for the path:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

6) Look for the same two entries at that path, and comment here whether either one exists.

Thanks.

Comment 7

[Onno]

This key "HEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\"

reads:

Mozilla Firefox 40.0.3 (x86 nl)

------

This key "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\"

Mozilla Firefox 41.0 (x86 nl)

Comment 8

[Ed Mullen]

(In reply to Onno from comment #0)
> Created attachment 8656879 [details]
> Double FF 40 entry.jpg
> 
> User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101
> Firefox/40.0
> Build ID: 20150826023504
> 
> Steps to reproduce:
> 
> FF updated to 40.0.3 from 40.0.2
> 
> 
> Actual results:
> 
> After that old entry of 40.0.2 is still listed also in the programs and
> Features list of Win10
> 
> 
> Expected results:
> 
> Only 40.0.3 should have been listed

I am on the Beta channel using 42.0b1 64-bit and the same thing happened to me. Windows 10 Pro.

I checked the registry as Onno suggested.  The first location shows nothing for Firefox.  The second listing only shows: Mozilla Firefox 42.0 (x64 en-US).

I first noticed this yesterday. Uninstalled FF.  I had a copy of 41.0b3 on hand so I installed that and let it update. Now I have two listings in Programs and Features:

Mozilla Firefox 41.0 (x64 en-US)
Mozilla Firefox 42.0 (x64 en-US)

There is only one installation of FF. If I click on version 41 and uninstall, it uninstalls version 42.

Ed Mullen

Comment 9

[Ed Mullen]

(In reply to Ed Mullen from comment #8)
> (In reply to Onno from comment #0)
> > Created attachment 8656879 [details]
> > Double FF 40 entry.jpg
> > 
> > User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:40.0) Gecko/20100101
> > Firefox/40.0
> > Build ID: 20150826023504
> > 
> > Steps to reproduce:
> > 
> > FF updated to 40.0.3 from 40.0.2
> > 
> > 
> > Actual results:
> > 
> > After that old entry of 40.0.2 is still listed also in the programs and
> > Features list of Win10
> > 
> > 
> > Expected results:
> > 
> > Only 40.0.3 should have been listed
> 
> I am on the Beta channel using 42.0b1 64-bit and the same thing happened to
> me. Windows 10 Pro.
> 
> I checked the registry as Onno suggested.  The first location shows nothing
> for Firefox.  The second listing only shows: Mozilla Firefox 42.0 (x64
> en-US).
> 
> I first noticed this yesterday. Uninstalled FF.  I had a copy of 41.0b3 on
> hand so I installed that and let it update. Now I have two listings in
> Programs and Features:
> 
> Mozilla Firefox 41.0 (x64 en-US)
> Mozilla Firefox 42.0 (x64 en-US)
> 
> There is only one installation of FF. If I click on version 41 and
> uninstall, it uninstalls version 42.
> 
> Ed Mullen

Sorry ... "...registry as Mark suggested."

Comment 10

[Molly Howell (she/her) (no longer active)]

Attachment: MozReview Request: Bug 1201734 - Prevent duplicate Windows uninstall entries; r?rstrong

Bug 1201734 - Prevent duplicate Windows uninstall entries; r?rstrong

This patch attempts to prevent the Windows Firefox installer and updater
from creating new uninstall registry entries when entries already exist
in another location. This should prevent multiple entries for Firefox
from appearing in the Programs and Features control panel.

The patch works by adding a check to the installer to determine whether
the selected installation directory is in a location specific to the
current user, or in a location common to the whole machine. It decides
this based on the owning group found in the access control list for the
part of the installation path that already exists prior to installation.
If the path is user-specific, then uninstall entries are created only in
the user-specific part of the registry. Otherwise, uninstall entries are
created only in the machine-level part of the registry.

During an update, the existing uninstall entries are found by searching
both locations for a set of entries which match the location of the Firefox
installation being updated. Entries for the updated version will then be
created in that same location, and not in the opposite registry hive,
as would have been possible before.

Note that this patch *does not* attempt to remove duplicate uninstall
entries if they already exist. That will have to be done manually.

Comment 11

[lmlb_lmlb]

AccessControl::GetFileGroup returns the localized name (for me it's "Administratörer" instead of "Administrators").

Comment 12

[Robert Strong (they/them - no direct email)]

Comment on attachment 8672838 [details]
MozReview Request: Bug 1201734 - Prevent duplicate Windows uninstall entries; r?rstrong

https://reviewboard.mozilla.org/r/21797/#review25363

We are trying to remove additional goto's and labels and I suspect that this can be written without using them.

Comment 13

[Robert Strong (they/them - no direct email)]

Also note comment #11

Comment 14

[Johnny Surething]

Firefox 43.0.3 -> 43.0.4 still burns people's OCDs.

Originally installation creates an uninstall entry here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

But the built-in updater creates an uninstall entry here:
HKEY_USERS\S-1-5-21-1797245533-2775765166-964391552-1001\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\

Comment 15

[Molly Howell (she/her) (no longer active)]

Comment on attachment 8672838 [details]
MozReview Request: Bug 1201734 - Prevent duplicate Windows uninstall entries; r?rstrong

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/21797/diff/1-2/

Comment 16

[Robert Strong (they/them - no direct email)]

I'll finish this review in the next few days.

Comment 18

[Robert Strong (they/them - no direct email)]

Comment on attachment 8672838 [details]
MozReview Request: Bug 1201734 - Prevent duplicate Windows uninstall entries; r?rstrong

https://reviewboard.mozilla.org/r/21797/#review28743

It seems to me that the SetUninstallKeys macro should just check whether it should be written to HKCU or HKLM. It should also be trivial to have the uninstall registry cleanup code should look for the install in all possible locations and remove them on uninstall and prior to calling the SetUninstallKeys macro. Does that make sense?

Comment 19

[Molly Howell (she/her) (no longer active)]

https://reviewboard.mozilla.org/r/21797/#review28743

It does. It makes enough sense that I'm not sure why I didn't just do that in the first place. In that case the only change is to run RegCleanUninstall on both hives; it doesn't matter where the initial SetUninstallKeys writes to, because then we'll find it either way, so there's no need to mess with that logic. The only scenario I can think of where that breaks is if an install were done by an elevated user and then a limited user attempted an upgrade or uninstall, but then of course that whole operation would fail anyway.
I'll rewrite this patch to work that way instead; I think it would out fine.

Comment 20

[Molly Howell (she/her) (no longer active)]

https://reviewboard.mozilla.org/r/21797/#review28743

Actually, it turns out that this is what we already do; everywhere that we run the uninstall key cleanup, we check under HKCU first, then find out if we can werite to HKLM and check under there too if so. So apparently the simple solution was not adequate.

Comment 21

[Robert Strong (they/them - no direct email)]

https://reviewboard.mozilla.org/r/21797/#review29549

What about the other part of the comment, "It seems to me that the SetUninstallKeys macro should just check whether it should be written to HKCU or HKLM."?

Comment 22

[Molly Howell (she/her) (no longer active)]

https://reviewboard.mozilla.org/r/21797/#review29549

SetUninstallKeys is currently making that decision by going with HKLM if it has write permissions there, or with HKCU if not and if there's not already a key in HKLM (nothing gets written at all in that case, to avoid duplicate entries).
The reason the check that my patch does couldn't go into SetUninstallKeys is that it has to be done before $INSTDIR is created, because that can change the result.

Comment 23

[Robert Strong (they/them - no direct email)]

I'm confused since SetUninstallKeys requires $INSTDIR. What are the cases as to why it needs to be checked before $INSTDIR is created?

Comment 24

[Molly Howell (she/her) (no longer active)]

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #23)
> I'm confused since SetUninstallKeys requires $INSTDIR. What are the cases as
> to why it needs to be checked before $INSTDIR is created?

The check depends on getting the owning group of the deepest directory in the install path that existed prior to the installation. It uses that to decide whether the location is machine-wide or controlled by a specific user. Once the directory has been created, I can no longer tell what the portion of it that existed before was, and the owner of the new directory is likely to be different from, say, Program Files.

Comment 25

[Ben Tremblay]

If there's some benefit, can bugs such as this be in some way marked to reflect that they're stale/dead? "Invalid"?
/bdt

Comment 26

[Molly Howell (she/her) (no longer active)]

The patch here needs to be pared down; I don't think there's any need to be so clever about where we write the uninstall key in the first place, all we need is a way to find if there's an existing one for the same path.