102308 - Simple MAPI: Simple MAPI fails if Communicator 4.x or Outlook is installed

Status: VERIFIED FIXED

(MailNews Core :: Simple MAPI, defect, P1)

Description

[Trix Supremo]

If Communicator 4.x or Outlook is installed, Simple MAPI will fail to call up
Mozilla's email client.

DESCRIPTION:
1. Install Communicator 4.x or MS Office(including Outlook).
2. Install Mozilla.
3. Set Mozilla to be the default email client.
4. Launch MSWord and attempt to send a document.

ACTUAL:
Outlook email client or Communicator's email client will be displayed instead of
Mozilla.

EXPECTED:
Mozilla should be displayed.

Comment 1

[Trix Supremo]

changed QA Contact to self

Comment 2

[Trix Supremo]

directions for installing the test build as well as the documentation for
testing Simple MAPI can be found on:

http://eclient.mcom.com/qa/emojo/index.html

Comment 3

[Tiantian Kong]

Hi:

I just phoned Chris, and explained about this bug, and our recommendation to
delay sending the test build to a big audience. 

He agrees that this is a sensible decision. 

We'll send the build out once we resolved this bug, hopefully over this weekend.

Comment 4

[WD]

Just a note:

On systems with IE5 or later, the Microsoft MAPI32.DLL file does look at the
DllPath registry value to know where the MAPI calls get sent to.  No file
replacement is necessary.

On IE4 systems or earlier, MAPI32.DLL ignores that registry key.  In such cases,
the Microsoft MAPI32.DLL must be replaced with the vendor-provided one when it
it selected as the default mail client.    (And the original MS MAPI32.DLL must
be restored when it is not set to be the default mail client)

Comment 5

[Tiantian Kong]

Reassigned to Srilatha, as the fix will be in her part of the code.

Comment 6

[Srilatha Moturi]

I checked in the fix into the private Branch. So now we copy Mozilla Mapi dll 
into the system directory when mozilla is set as the default mail client and 
restore the previous dll when this preference is unset.

Comment 7

[Hong Kwon]

I thought we were trying to avoid copying anything into the System directory due
to the possibility of the current user not having the right permissions.  Is
this no longer the case?

Comment 8

[lchiang]

tiantian, I assume you want to nominate this for nsbranch?

Comment 9

[Rajiv Dayal]

We were trying to avoid copying into system dir since we did not want to break
Outlook. Usually the "restricted" Windows users donot have rights on the system
directory. If the current user is the restricted user even the solution of
changing the MAPI registry key will fail since a restricted user does not have
"write" access to this MAPI registry key too.

As mentioned by WD, MS provides a version of mapi32.dll (lets call it smart MAPI
dll) which checks the windows registry key to figure out which is the default
mail client and passes the MAPI call to the default client's version of MAPI
Dll. Thus there is no need to replace the file.

However there are other messaging apps (older versions) which replaces the
mapi32.dll in system dir. Thus if these apps are already installed on the system
when we install Mozilla there is no choice but to replace the existing dll (the
other app's versions) with our Mozilla version. We tried to see if we could for
sure figure out if the existing one is the smart dll and donot replace it, but
have not yet been able to.

Although we replace the existing dll we back it up. And also we provide the
Preference. So if the user wants to get back the earlier app as the default or
make Outlook work, he/she just need to uncheck the checkbox and the MAPI state
would be as it was before making Mozilla as the default client.

Comment 10

[WD]

Rajiv, I've got the info you need, but it's written down in my notebook at work.
 Basically it involves checking the properties of the MAPI32.DLL file in the
Windows System directory: 
1) Is the CompanyName "Microsoft Corporation"?   2) Is the ProductVersion number
one of the "smart" ones?

I can post this info on Tuesday when I get back to work.  (If you're interested
in pursuing the non-file-replacement method on systems with this "smart" mapi32.dll)

Comment 11

[Jaime Rodriguez, Jr.]

May need L10N approval for UI changes.

Comment 12

[Michele Carlson]

We really can't accept any UI changes now. It's too late. But do we have a choice?

Comment 13

[Krishna Mohan]

I don't think any UI changes are required.  We have a solution that is already 
checked in to private MAPI_SUPP_BRANCH, but I am trying to refine it.

Comment 14

[WD]

There are 2 ways a machine can get the "Smart" MAPI32.DLL file.
1) Install MS Outlook (any version)
2) Install IE5 (Outlook Express 5)

Just by looking at MAPI32.DLL, you can check if it's the smart one by looking at
the file properties:
Company Name = "Microsoft Corporation"
Product Version = "1.0"

If the Company Name check fails, then some other, non-MS mail client is the
default one.  (Eudora, etc...)   In this case MAPI32.DLL must be replaced by the
Mozilla one when it's selected as the default mail client and restored back
again when Mozilla is de-selected from being the default mail client.

If the Product Version check fails, then the MAPI32.DLL is a Microsoft one, but
it's not "smart", and needs to be replaced as described above.   Such possible
values here are 4.0, 5.5 (From MS Exchange client I believe), or 6.0 (From
Outlook Express 4.0).   These files, although they have a greater version number
than 1.0, are older and they are *not* the "smart" ones.

If both the Product Version and Company Name match, then the system has the
proper DLL file for using the DllPath registry key and no file replacement is
required!

Comment 15

[Rajiv Dayal]

In case when we replace the existing mapi32.dll we need to take care of it
during the uninstall. A user may select Mozilla as the default mail client and
then without unsetting it from the Prefs, may uninstall Mozilla. In this case
uninstall should replace the mapi32.dll with the backed up mapi32.dll
(mapi32_moz_bak.dll) and delete the mapi32_moz_bak.dll.

Also in case of a similiar scenario as below : 
1) N4.7 set as default mail client, mapi32.dll is from N4.7
2) Mozilla made the default mail client, mapi32.dll is from Mozilla,
mapi32_moz_bak.dll is from N4.7
3) Outlook made the default client, mapi32.dll is from Outlook

Now during uninstall we need to take care we donot replace this mapi32.dll from
Outlook with the backed up dll which is from N4.7. To take care of this,
uninstall will check if the current dll is from Mozilla and replace it with the
backed up one only if it is.

The following are the changes for this :
1) Modify uninstall to do the above.
2) New method "GetMozMapiDllVersion" exported by mapi32.dll
3) Store the backed up dll path in registry key

Comment 16

[Srilatha Moturi]

I checked in the code for setting the registry key when we switch the dll.
This is the key that we set.
[HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Desktop]
"Mapi_backup_dll"="D:\\WINNT\\SYSTEM32\\Mapi32_moz_bak.dll"

Comment 17

[Rajiv Dayal]

I have checked in the changes for the exported DllVersion method into the
MAPI_SUPP_BRANCH. The name of the exported function is :
'MAPIGetNetscapeVersion'. A similiar function also exists for the mapi dll for
N4.7. Sean, u will need to call this function and if it returns 94 (Mozilla 094)
it means it is from us.

Comment 18

[Srilatha Moturi]

Attachment: patch v1

Comment 19

[Scott MacGregor]

Comment on attachment 51823 [details] [diff] [review]
patch v1

In setDefaultMailClient can you change:
if (!NS_SUCCEEDED(CopyMozMapiToWinSysDir()))

to
if (NS_FAILED(CopyMoz....))

same thing in unsetDefaultMailclient.

then
sr=mscott

Comment 20

[Rajiv Dayal]

For below :

+((nsFileSpec*)&binDir)->GetNativePathString(mozFilePath);
+
+    nsCAutoString mozFile;
+    if (!mozFilePath.IsEmpty()) {
+        mozFile.AppendWithConversion(mozFilePath.get());
+        mozFile.Append("mozMapi32.dll");
+    }
+
+    nsCOMPtr<nsILocalFile> pMozMapiFile = do_CreateInstance
(NS_LOCAL_FILE_CONTRACTID, &rv);
+    if (NS_FAILED(rv) || !pMozMapiFile) return rv;
+    pMozMapiFile->InitWithPath(mozFile.get());


u need not create var mozFile, just AppendWithConversion("mozMapi32.dll") to
mozFilePath and do pMozMapiFile->InitWithUnicodePath using mozFilePath.

Besides this change r=rdayal.

Comment 21

[Rajiv Dayal]

The above comments is for attachment id=51823.

Comment 22

[Srilatha Moturi]

Attachment: patch v2

Comment 23

[Srilatha Moturi]

The new patch has the changes suggested by mscott and rajiv. I changed the other  
occurrences of InitWithPath to InitWithUnicodePath.

Comment 24

[Srilatha Moturi]

oops, forgot to remove the commented lines. new patch coming right away

Comment 25

[Srilatha Moturi]

Attachment: patch v3, removed commented lines

Comment 26

[Rajiv Dayal]

Comment on attachment 51908 [details] [diff] [review]
patch v3, removed commented lines


u need to set the Win registry for Mapi_backup_dll only if the Mapi32_moz_bak.dll
file gets created. In case if there is no previous mapi32.dll this
Mapi32_moz_bak.dll file is not created.

Comment 27

[Srilatha Moturi]

Attachment: patch v4, checking if the dll we have is smart dll

Comment 28

[Srilatha Moturi]

In the latest patch, we swap the dll only if the mapi32.dll is not a smart dll.
Also made some changes based on Rajiv's suggestions in the 
CopyMozMapiToWinSysDir() such that we set the registry key only if mapi32.dll 
exists.

Comment 29

[Rajiv Dayal]

From update of attachment (id=51971) :  r=rdayal.

Comment 30

[Rajiv Dayal]

Hey Sean, can u please put the patch for removing the backup file during
uninstall here. thanks.

Comment 31

[Scott MacGregor]

Comment on attachment 51971 [details] [diff] [review]
patch v4, checking if the dll we have is smart dll

sr=mscott

Comment 32

[Sean Su]

please reasign this bug to me when the patches have landed.

Comment 33

[Jaime Rodriguez, Jr.]

pls check this into the branch - PDT+

Comment 34

[Sean Su]

I have filed a new bug regarding the uninstall problem:
  bug 103232

Please add comments relating to uninstall and simple mapi there.

ps. you no longer need to reassign this bug to me when your done with it.

Comment 35

[Srilatha Moturi]

Checked into the MOZILLA_0_9_4_BRANCH

Comment 36

[WD]

After installing the latest 0.9.4 (2001100503) and selecting Mozilla to be the
default mail client, MapiLogon causes a Netscape 4.x session to be launched.

My MAPI32.DLL file is the "smart" one (From Outlook 2000)
HKLM\SOFTWARE\Clients\Mail\(Default) is "Mozilla"
HKLM\SOFTWARE\Clients\Mail\Mozilla\DLLPath is "C:\MOZILLA\BIN\mozMapi32.dll"

So I tried copying mozMapi32.dll directly over MAPI32.DLL just to be sure.  
Netscape 4 is still launched when accessing Simple MAPI!   Quite odd....

Comment 37

[lchiang]

I think you have to disable the preference in 4.x to use MAPI for sending. 
Esther, is this what you had discovered?  WD- can you try this?

Comment 38

[Srilatha Moturi]

WD, it is quite odd, the registry settings seem to be fine.
Can you check the preferences in 4.x.
Is the preference in 4.x, Use Messenger for MAPI based applications...checked or 
unchecked.
If it is checked can you uncheck it and try again.

Comment 39

[Srilatha Moturi]

Lisa, you do not have to uncheck the 4.x preference anymore, with today's build. 
WD can you try today's build.

Comment 40

[WD]

I don't currently have access to the machine where I noticed the problem, but
hopefully I can test something in a few days.

Now, I don't know for absolute sure that netscape mail was being used to receive
mapi calls, but here's what I saw:

I have a VB test application which has several different functions composed of
VB code and Simple MAPI calls.   There are functions such as logging on, logging
off, send a message, send a message with attachment, list all messages in inbox,
delete message from inbox, forward, find first message in time, find last
message in time, etc...

Now, even to this date pretty much the only things that work are Logon and
Logoff.  The others either give a Runtime Error 32002: Unspecified error, or
cause the software to hang (in a loop).  

When I tested the software, I didn't have Netscape or Mozilla running.   When I
used the software to do a simple MAPI logon, it launched a Netscape window and
did log on.   I assumed it was logging on to netscape.   Perhaps the code to
launch mozilla if it isn't currently running isn't quite working right?

Also, with respect to the other functions of my VB program not working.  I'm
assuming this is because Simple MAPI support is still a work-in-progress?   Is
there any place I can check what is and what is not implemented yet?

Comment 41

[Tiantian Kong]

Fixed in 0.9.4 branch

Comment 42

[Trix Supremo]

verified on 2001-10-12-05-0.9.4

Comment 43

[Jaime Rodriguez, Jr.]

hmmmmm ... curious to know how this was verified as fixed before a build was
released. pls advise ...

Comment 44

[Tiantian Kong]

The patch was checked in on 10/4. 

We did not mark it as fixed on branch immediately, because I thought we can only
mark as fixed once the bug is checked into the trunk.

Comment 45

[Srilatha Moturi]

WD, have you tried today's build. Do you still see the problem you described 
above. 
---Perhaps the code to launch mozilla if it isn't currently running isn't quite 
working right?
This is working fine. 

--Also, with respect to the other functions of my VB program not working.  I'm
assuming this is because Simple MAPI support is still a work-in-progress?   Is
there any place I can check what is and what is not implemented yet?

The APIs that are implemented are Logon, Logoff, SendMail and SendDoc. With the 
latest builds you will not get the Logon Dialog. You can look bug 91702.
WD if you still see these problems I would suggest, we should open a new bug on 
this. since the actual problem reported in this bug is fixed.