Workaround for Default Browser Not Coming Up (Firefox + Thunderbird)

If you are using both Firefox and Thunderbird in SVS layers (and after all, what self-respecting gearhead wouldn't be!?), and if Firefox is configured as your default browser, maybe you've noticed that clicking on HTTP links doesn't always work. Sometimes (a good example being in SVS Admin, Help > Altiris Juice), nothing happens. No error. Just stillness and the quiet chirping of crickets in the distance...

The reason is a known defect around how SVS handles the resolution of short file names. The default installation paths for these apps are:

C:\Program Files\Mozilla Firefox
C:\Program Files\Mozilla Thunderbird

SVS sees both as:

C:\Progra~1\Mozill~1

So, when it comes time to find the app associated with opening HTTP in HKEY_CLASSES_ROOT, Windows finds "C:\Progra~1\Mozill~1\firefox.exe" and... Guess what? SVS sometimes (not always) makes Windows look in the wrong place ("Mozilla Thunderbird" instead of "Mozilla Firefox"), in which case firefox.exe is not found and nothing happens. I don't know if it's truly arbitrary or related to layer activation order or what. I'd ask the engineers, but they have more important things to do... like fixing this bug. :)

I'm not sure why Firefox uses short name syntax in the command value for its CLASSES settings. But it does, and due to the SVS bug you get unreliable behavior. There are several workarounds. One would be to install either Firefox or Thunderbird to alternate paths that will resolve uniquely despite our bug.

Assuming you don't want to go back and do that, replace the short name syntax with long name syntax in the following locations, in the Firefox layer, using the Advanced Layer Properties Editor:

HLM\SOFTWARE\Classes\FirefoxHTML\shell\open\command
HLM\SOFTWARE\Classes\HTTP\shell\open\command
HLM\SOFTWARE\Classes\HTTPS\shell\open\command

...and then your beloved Firefox will always come up, as designed.

Editor's Note (added 12/20/06): It came to Scott's attention after he wrote this that if you have Firefox set to "always check to see if Firefox is the default browser on startup," it will change the registry entries back to the short path and re-introduce the problem above. So you can de-select that option, but he says best practice is definitely to install Firefox to a non-default path. Scott plans to change the install path in his Firefox 2.0.0.1 VSA that should be uploaded here later today.