How Does Your Browser Know that It's Not The Default?

On Windows system, how does your browser tell that it’s currently not the default? Prior to Windows Vista, this information is stored in the registry under HKEY_CLASSES_ROOT hive, the usual place where all shell associations are kept. The default browser is maintained under HKEY_CLASSES_ROOT on per-protocol basis (as well as per file type basis, but I’m only interested in the protocols since we use browsers most of the time to access online resources, not offline). The convention for registry locations, where protocol-application associations are stored; is “HKEY_CLASSES_ROOT\[protocol]\shell\open\command “. Substitute [protocol] here with http, https, ftp, gopher or other protocols commonly supported by your favorite browser.

For example: if I want to know what is the default program for opening http protocol, then I’ll look at the registry value of “HKEY_CLASSES_ROOT\http\shell\open\command”. If I go to Start menu, click Run, type “http://newoldthing.wordpress.com” and then hit Enter, the URL will be opened with the application of which command line is registered in this registry value. As simple as that.

The next question will be, whether the default browser is maintained on per-user basis or it’s a system wide setting. If it’s maintained on per-user basis, then if user A set his default browser, then it will not change the default browser for user B or C. This would be somewhat the desired behavior, don’t you think? Imagine a family whose members are computer versed or so they thought, sharing one PC, and they constantly have fight over IE vs Firefox vs Opera. You don’t want the default browser to be system wide setting in that family’s PC.

But unfortunately, the answer is not straightforward. The default browser setting can be both per-user and system-wide. To understand this, you need to understand HKEY_CLASSES_ROOT hive. There’s no better place to start than MSDN documentation. In summary, there are 3 important concepts about HKEY_CLASSES_ROOT that we have to keep in mind:

1. The HKEY_CLASSES_ROOT key provides a merged view of “HKEY_LOCAL_MACHINE\Software\Classes” (contains default settings that can apply to all users on the local computer) and “HKEY_CURRENT_USER\Software\Classes” (contains settings that apply only to the current interactive user).
2. The user-specific settings have priority over the default settings.
3. If you write values to a key under HKEY_CLASSES_ROOT, the values will go under:
   • HKEY_CURRENT_USER\Software\Classes; if the key exists under HKEY_CURRENT_USER\Software\Classes.
   • Otherwise, HKEY_LOCAL_MACHINE\Software\Classes.

Windows basically requires browsers to do the right thing to make the settings per-user basis instead of system-wide. In ideal scenario, before writing the default browser settings to HKEY_CLASSES_ROOT, browsers need to check if the key already exists under HKEY_CURRENT_USER or not. If the key exists there, then writing to HKEY_CLASSES_ROOT will be equal to committing to HKEY_CURRENT_USER; meaning that the settings will only affect the current interactive user and not other users. If the key doesn’t exist, then no question the key must be written under HKEY_CURRENT_USER instead of HKEY_CLASSES_ROOT. However, most (if not all) browsers basically write to HKEY_CLASSES_ROOT blindly, and since the protocol-association registrations do not exist under HKEY_CURRENT_USER by default, that means browsers write the settings to HKEY_LOCAL_MACHINE all the time. That is not only annoying and disruptive, the attempt to overwrite default browser may ultimately fail as well.

Consider the scenario of standard or limited user accounts. They don’t have write access to HKEY_LOCAL_MACHINE\Software\Classes. So if standard user says “Yes” when asked by browser X to set X as default browser, and X writes the settings to HKEY_CLASSES_ROOT which ultimately passed-through to HKEY_LOCAL_MACHINE; the registry write operation will fail. As a result, browser X will ask the same question next time it’s launched by this standard user. More frustration for the user!

Realizing these bad-eggs and with good intentions to prevent users from stepping on each other’s toes, 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]“. Windows Vista’s shell will launch a URL with an application associated with the URL’s protocol based on the value of these registry keys. Browsers that were not aware of this change broke on Vista, they were simply unable to set itself as default browser (they saw themselves as default browser although shell didn’t think so because the twos were looking at 2 different registry keys).

Windows shell team introduced a new shell object called ApplicationAssociationRegistration to allow application registering itself as default for a particular type or protocol, as well as querying the current default. This shell object is only available on Vista, and therefore incorporating that in the code that is also targeted for previous Windows versions needs to be done with care. Tomorrow I’ll talk about how to use ApplicationAssociationRegistration shell object in a code base that is not exclusively targeted for Vista.

About these ads