699803 - Set required HKLM keys / values for default browser if they are not set using the maintenance service

Status: RESOLVED INVALID

(Firefox :: Shell Integration, defect)

Description

[Brian R. Bondy [:bbondy]]

There are a couple UX issues with how we set the default browser on Vista and up.

1) Limited user accounts can't set their default browser without having an administrative password
2) With Administrative accounts we give a UAC prompt, hence giving the user an extra way to opt out after they already decided that we should be the dfault browser. 
 
When we set the default browser we launch helper.exe to do the work.
It writes these registry values:
helper.exe sets the default browser via the normal keys: 
HKCU\Software\Classes\
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\
HKCU\Software\Microsoft\Windows\Shell\Associations\

But it also sets the following:
HKLM\SOFTWARE\Clients\StartMenuInternet\*
HKLM\SOFTWARE\RegisteredApplications\Firefox
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\

As of Vista programs are registered per user instead of per computer. 
I don't think there is much value in setting the HKLM values. 
We could set the default HKLM values without the UAC prompt using the service, but I think it's better to simply not write those values on Vista and up.  We would still write them for XP, Windows Server 2003, and below.

Comment 1

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

Brian, could you verify that it shows the UAC when the HKLM keys / values are already correctly set?
HKLM\SOFTWARE\Clients\StartMenuInternet\*
HKLM\SOFTWARE\RegisteredApplications\Firefox

Actually, with Windows versions previous to Vista the default protocol handlers are already user specific. With Vista and above there is the additional requirement for the HKLM keys / values under RegisteredApplications to also be correctly set. btw: iirc the same is true for registering as the system application.

The StartMenuInternet is still used with Vista so they are also set at the same time. Regretfully, these values point to a specific install and changing them can mess up a second user of the system.

I assume HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ is a mistake since we shouldn't be setting that key.

Also, as long as the RegisteredApplications keys / values are present we use HKCU to properly register the protocol handlers that the keys / values under RegisteredApplications point to.

Comment 2

[Brian R. Bondy [:bbondy]]

> Brian, could you verify that it shows the UAC when the HKLM keys / values are already correctly set?

It will only show the UAC if they are not set to us. 

> I assume HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ 
> is a mistake since we shouldn't be setting that key.

I was using sysinternals procmon with an appropriate filter to get this data, so this is probably something that is written to unrelated that happened to show up.

--

Do you think it would be best to always set the HKLM and use the service to launch helper.exe if installed?

Note: Chrome will only set the HKCU values and it works correctly to launch the default browser for that user.

Comment 3

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

Last I checked chrome when I set it as default it did show a UAC prompt so it could set up the required HKLM keys. After they are setup, there is no UAC prompt just like us.

I could see us setting the HKLM keys / values for StartMenuInternet and RegisteredApplications using the service if and only if they are not already set. I don't think the current functionality should change though since we also have to deal with the Vista and below StartMenuInternet keys / values which are installation specific.

Comment 4

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

btw: the chrome method is a tad broken because the point HKLM keys to installs under a specific user's %LOCALAPPDATA% directory.

For example:
HKLM\Software\Clients\StartMenuInternet\Google Chrome\InstallInfo
ReinstallCommand =
"C:\Users\username\AppData\Local\Google\Chrome\Application\chrome.exe" --make-default-browser

Comment 5

[Brian R. Bondy [:bbondy]]

I'm only looking at post installation by the way.
So once Chrome, Firefox and Aurora are all installed here are my observations:

Let's say Firefox is currently the default browser.
- Any future attempts to set Chrome as the default browser will only modify the HKCU values even if they are not set in the HKLM values.
- Any future attempts to set Aurora as the default browser will prompt for UAC, if you are a limited user it will ask for the administrative password.

Note: I am seeing this a lot lately because I install so many Nightlies, so I accidentally always set Nightly as my default browser, and then when I open up my main browser (Aurora) it does a UAC prompt to reset the default browser.

Comment 6

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

That would be the check for the StartMenuInternet keys which aren't used on Windows 7 so that could be disabled to prevent that on Windows 7. On Vista and below it would still be necessary since there are keys / values pointing to a specific install. One of the ways chrome gets away with not doing this is because they don't allow Canary to be set as default last I checked and they only allow installing into a specific directory for Canary, Release, etc.

Comment 7

[Brian R. Bondy [:bbondy]]

I was reading the info about Vista and later using per user here by the way:
http://newoldthing.wordpress.com/2007/03/23/how-does-your-browsers-know-that-its-not-the-default-browser/

> Windows Vista introduces new way of registering default browser. 
> It’s part of the new feature called Default Programs. It’s different to 
> Windows XP’s SPAD (Set Program Access and Defaults) in that Default Programs 
> is primarily controlled at the per-user level instead of per-machine level 
> (out of the box! And does not rely on 3rd party programs to do the right thing). 
> As part of this Default Programs, the default browser settings are now stored under 
> “HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\ Associations\UrlAssociations\[ftp|http|https]“

Comment 8

[Brian R. Bondy [:bbondy]]

Aren't the old values in HKLM and HKCU merged w/ higher priority to HKCU anyway?  Would it be acceptable to only write to HKCU from limited user accounts?  

Of course this discussion is probably unneeded if we simply use the service to do the work.

Comment 9

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

The part that is left out is that HKLM\SOFTWARE\RegisteredApplications\ needs to be setup at install time. If the user installs without admin and with our zip builds that isn't possible.

Comment 10

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

(In reply to Brian R. Bondy [:bbondy] from comment #8)
> Aren't the old values in HKLM and HKCU merged w/ higher priority to HKCU
> anyway?
No, they are not for both RegisteredApplications and StartMenuInternet

>  Would it be acceptable to only write to HKCU from limited user
> accounts?
RegisteredApplications and StartMenuInternet are not read for these values from HKCU
  
> 
> Of course this discussion is probably unneeded if we simply use the service
> to do the work.
The problem is with StartMenuInternet as I already stated. We support side by side which means that you can set any install as the default browser. We could add the complexity you are suggesting but the only real value is going to be for people with multiple installations since users that install without admin won't have the service and zip builds likely won't have the service. I personally don't think the additional complexity to support this case for side by side installs (e.g. by far not anywhere near the majority of users) where you will need to tell the service about the specific install so the StartMenuInternet keys are correctly written is worth all that much.

Comment 11

[Rachel Tublitz [:rachel]]

We're setting the keys per user now, going to close this one out.