Make |nsMapiRegistryUtils::unsetDefaultMailClient()| safer



MailNews Core
Simple MAPI
16 years ago
6 years ago


(Reporter: Rajiv Dayal, Unassigned)


(Blocks: 1 bug)

Windows NT

Firefox Tracking Flags

(Not tracked)



(1 attachment)



16 years ago
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
> look into this .. maybe there should not be a pref associated with this at
> 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
> 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

------- 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).

Comment 1

16 years ago
Created attachment 69794 [details] [diff] [review]
patch to prevent non-Mozilla mapi32.dll file from being deleted

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

Comment 2

16 years ago
Link to Comment#20 mangled to this bug id, should be #122377 (trying to maintain
the paperless trail :)

Correct link:

Comment 3

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

Comment 4

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


16 years ago
QA Contact: trix → yulian
QA Contact: yulian → stephend


15 years ago
Blocks: 109362
Product: MailNews → Core
Assignee: thieleke → nobody
QA Contact: stephend → simple-mapi
Summary: make MAPI unsetdefaultMaiClient function safer → Make |nsMapiRegistryUtils::unsetDefaultMailClient()| safer


10 years ago
Product: Core → MailNews Core

Comment 5

6 years ago
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.
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.