Closed Bug 356241 Opened 18 years ago Closed 17 years ago

Duplicate the behavior of IE when setting Firefox as the default browser

Categories

(Firefox :: Shell Integration, defect)

2.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: robert.strong.bugs, Assigned: robert.strong.bugs)

References

Details

(Keywords: verified1.8.1.2)

This applies to OS's prior to Vista

What I am seeing with IE:
1.a Admin user with no handlers under HKCU\Software\Classes with handlers under HKLM\Software\Classes
Take handlers under HKLM\Software\Classes

1.b Admin user with handlers under HKCU\Software\Classes AND HKLM\Software\Classes
Take handlers under HKLM\Software\Classes AND HKCU\Software\Classes

1.c Non-Admin user with handlers under HKCU\Software\Classes AND HKLM\Software\Classes
Take handlers under HKCU\Software\Classes

What I am seeing with Firefox:
2.a Admin user with no handlers under HKCU\Software\Classes with handlers under HKLM\Software\Classes
Take handlers under HKLM\Software\Classes

2.b Admin user with handlers under HKCU\Software\Classes AND HKLM\Software\Classes
Take handlers under HKCU\Software\Classes

2.c Non-Admin user with handlers under HKCU\Software\Classes AND HKLM\Software\Classes
Take handlers under HKCU\Software\Classes

So, 2.b is not the same as 1.b

Also, because of the way we set handlers we can end up with some of them being set under HKLM and some under HKCU for the admin user. If we pass false for aForAllUsers when calling OpenKeyForWriting we check for the existence of the key in HKCU and if it doesn't exist we fallback to HKLM. So, if it is found under HKCU we won't update HKLM.

http://lxr.mozilla.org/seamonkey/source/browser/components/shell/src/nsWindowsShellService.cpp#101
note: this code should be tagged as "things that make you go huh...?" :/

We pass false for aForAllUsers to SetDefaultBrowser which is passed to SetRegKey which is passed to OpenKeyForWriting which then tries to open the key in HKCU per the value of aForAllUsers and if the key doesn't exist in HKCU it tries to create it in HKLM. Guess this worked most of the time since most people run as admin on windows.
This will be fixed by bug 354005
Depends on: 354005
Fixed by the checkin of bug 354005
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Blocks: 369465
Keywords: fixed1.8.1.2
Version: Trunk → 2.0 Branch
note: since the default app code had to be rewritten for Vista I went ahead and fixed this bug at the same time as the other changes for 2.0.0.2
To verify on WinXP we should always set if we have admin rights .htm, .html, .shtml, .xht, and .xhtml under HKLM Software\Classes\ with a default value of FirefoxHTML, set the http, https, ftp, and gopher keys with a shell\open\command of <path to firefox>\firefox.exe -url "%1" -requestPending and shell\open\ddexec default value of "%1",,0,0,,,, as well as shell\open\ddexec\Application with a default value of Firefox and shell\open\ddexec\Topic with a default value of WWW_OpenURL.

If we don't have rights we should set the keys under HKCU.
verified fixed on the 1.8 branch using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/2007021518 Firefox/2.0.0.2. Running on Win XP as an admin with Firefox set as default, I can confirm all values rstrong cites in Comment 4. Adding keyword.
You need to log in before you can comment on or make changes to this bug.