The function nsMapiRegistryUtils::unsetdefaultMaiClient should not do anything if the mapi Dll in system dir is not Mozilla's version. ------- Additional Comment #14 From Jeff Thieleke 2002-02-05 04:02 ------- Created an attachment (id=67889) Updated patch to prevent non-Mozilla mapi32.dll files from being deleted > the pref changed code should be the one that should change in this case. I will > look into this .. maybe there should not be a pref associated with this at all > since the settings for default Mail client (MAPI preferences) is stored in > Windows registry and that is the one that should be checked (and which is also > checked currently) rather than keeping another pref for it. The registry setting (HKLM\Software\Clients\Mail) is only effective if you are using the MAPI stub DLL, the so-called smart DLL. The first problem is not all users will have the stub DLL, since it wasn't introduced until Windows 2000, IE 5, or Outlook 2000. In addition, if the user is using an older mail client, such as Netscape 4, it will typically remove the stub DLL and replace it with its own version. So Mozilla will still need to be able to do the messy business of replacing mapi32.dll with its own version, and switching back when it is no longer the default MAPI client. What it shouldn't do, and what my patch addresses, is deleting some other client's mapi32.dll just because unsetDefaultMailClient() is called and there is no Mapi32_moz_bak.dll available. Rajiv, your point about having to delete mapi32.dll even when no backup is available when Mozilla is unselected as the default MAPI client is taken. While the prefs issue should be addressed, modifying unsetDefaultMailClient() to not delete some other client's mapi32.dll must also be done. This function already has a check to prevent the deletion of the stub DLL, so my latest patch is just extending the check to also avoid deleting other non-Mozilla mapi32.dll files. ------- Additional Comment #21 From Jeff Thieleke 2002-02-09 00:58 ------- The behavior that Ian describes in Comment #20 occurs in nsMapiRegistryUtils::unsetDefaultMailClient() when HKLM\Software\Clients\Mail is empty or missing (name.IsEmpty()). This registry problem, as well as the non-Mozilla mapi32.dll deletion described in the comments above, are resolved when the patch in attachment (id=67889) is applied. Can I get a review on this patch? I think it is pretty clear that the patch in id=67889 does the right thing, since Mozilla should not be touching either the registry or mapi32.dll when it isn't the default MAPI client. If we want to fix the problem of {un}setDefaultMailClient() being called at app startup, then that's good, but unsetDefaultMailClient() should be fixed now. ------- Additional Comment #22 From Ian Jefferies 2002-02-09 10:05 ------- >The behavior that Ian describes in Comment #20 occurs in >nsMapiRegistryUtils::unsetDefaultMailClient() when HKLM\Software\Clients\Mail is >empty or missing (name.IsEmpty()). Just to clarify: this HKLM\Software\Clients\Mail value is the one stored in the branch HKLM\Software\Mozilla\Desktop (presumably as the backup of the setting Moz originally found.) The HKLM\Software\Clients\Mail registry branch as used by the MAPI smart stub DLL is correctly set to my expected mail client (Turnpike), and is neither empty nor missing when Moz overwrites it. IMHO unsetDefaultMailClient() should be smart enough to leave the system untouched if it determines that no change is required or possible. Given that the purpose of the function is to make changes to the system that other applications use, that function should not rely on the caller to protect it (supporting Jeff's position).

patch moved in from bug # 122377 since that is fixed.

Link to Comment#20 mangled to this bug id, should be #122377 (trying to maintain the paperless trail :) Correct link: http://bugzilla.mozilla.org/show_bug.cgi?id=122377#c20

*** Bug 145201 has been marked as a duplicate of this bug. ***

*** Bug 145201 has been marked as a duplicate of this bug. ***

Is this still relevant? I can't find a unsetDefaultMailClient function in whole comm-central. Also, the shell-service does not seem to have a function to unset TB as the default client.

Bug 353906 started killing this for Thunderbird and bug 441050 finished it off with SeaMonkey. So definitely no longer necessary.