Inconsistent drive letter case leading to invalid/duplicated registry entries

RESOLVED FIXED in Firefox 67

Status

()

enhancement
P3
normal
RESOLVED FIXED
7 months ago
3 months ago

People

(Reporter: rstrong, Assigned: rstrong)

Tracking

unspecified
Firefox 67
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox67 fixed)

Details

Attachments

(1 attachment)

Under HKLM Software\Clients\StartMenuInternet\Firefox-A3710B8EBB50CD3 I noticed a registry entry with a shell\open\command path that starts with a lowercase c.
"c:\Program Files\Nightly\firefox.exe"

When I already have HKLM Software\Clients\StartMenuInternet\Firefox-4FD8BA6A4A33F689 a shell\open\command that starts with an uppercase C
"C:\Program Files\Nightly\firefox.exe"

Interestingly, I only have FirefoxHTML-A3710B8EBB50CD3 and FirefoxURL-A3710B8EBB50CD3 under HKLM Software\classes and they both start with the uppercase C.

I've also noticed a couple of HKLM Software\classes\FirefoxHTML-<hash> and HKLM Software\classes\FirefoxURL-<hash> keys that only have shell\open\ddeexec and their values but don't have shell\open\command or DefaultIcon.
Bah, just noticed that HKLM Software\Clients\StartMenuInternet\Firefox-A3710B8EBB50CD3 has the uppercase C and HKLM Software\Clients\StartMenuInternet\Firefox-4FD8BA6A4A33F689 has the lowercase c which makes much more sense.
Yeah, this sounds like $INSTDIR is getting initialized with inconsistent drive letter casing. I'm not sure how that's happening, presumably NSIS is setting $EXEDIR that way, but in any case that difference then causes ${InitHashAppModelId} to generate different hashes. I guess ${GetLongPath} needs to be normalizing the case of the drive letter. And once that's happening we should also probably take steps to make sure we don't create duplicate entries for installs that had previously always used the other case.
Priority: -- → P3
Summary: Invalid registry entries created by the installer code → Inconsistent drive letter case leading to invalid/duplicated registry entries

Always uppercase the first char of the path in GetLongPath
Remove GetLongPathNameW since it isn't setting the proper case for the path segments below the leaf name

Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED

Comment 4

4 months ago
Pushed by rstrong@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a9bb4a23d407
Fix GetLongPath so it returns the proper case for the path. r=mhowell

Comment 5

4 months ago
bugherder
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 67
You need to log in before you can comment on or make changes to this bug.