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)
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
Assignee | ||
Comment 1•18 years ago
|
||
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.
Assignee | ||
Comment 3•17 years ago
|
||
Fixed by the checkin of bug 354005
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•17 years ago
|
Assignee | ||
Comment 4•17 years ago
|
||
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
Assignee | ||
Comment 5•17 years ago
|
||
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.
Comment 6•17 years ago
|
||
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.
Keywords: fixed1.8.1.2 → verified1.8.1.2
You need to log in
before you can comment on or make changes to this bug.
Description
•