361233 - installation of 1.1b breaks mapi linkage from excel and word

Status: RESOLVED FIXED

(MailNews Core :: Simple MAPI, defect)

Description

[brian lehrhoff]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061030 SeaMonkey/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061030 SeaMonkey/1.0.6

after installing 1.1b, can't attach documents from word or excel via mapi.

Reproducible: Always

Steps to Reproduce:
1.installed 1.1b
2.opened word
3.opened existing document
4.file/send/to mail as attachment
5. got message "login failed. you must login to microsoft exchange to access your address book.
6. similar message in excel.
7. system restore corrected issue.
8. re-install of 1.1b broke it again.

(using moz for mail, not outlook.)




something is obviously breaking the mapi or ldap settings in the registry.  i can offer a before-and-after export, but i have no way to compare ... nor do i know what to compare ...

Comment 1

[Christian Franke]

The bug can also be reproduced with other apps using MAPI like OpenOffice 2.1 or the "Send To|Mail recipient" function of explorer.

After installing SM 1.1b on XP SP2, MAPI does no longer work.

Result when examining the old MAPI Sample "smpcli32" from Win32 SDK in debugger:

With SM 1.1b, the call:

  result = MAPILogon ((ULONG) hWnd, NULL, NULL,
             MAPI_LOGON_UI | MAPI_NEW_SESSION, 0, &lhSession))

successfully loads mozMapi32.dll but returns MAPI_E_FAILURE.

The error code is likely returned by InitMozillaReference():
http://lxr.mozilla.org/seamonkey/source/mailnews/mapi/mapiDll/MapiDll.cpp#109

After re-installing SM 1.0.7, the SM MAPI works again.

This regression should IMO block 1.1

Comment 2

[Christian Franke]

Don't see differences between 1.1b and 1.0.7 in MAPI related registry entries and *mapi*.dll install locations. So this is probably not an installer issue, suggest to change Product/Component to Core/Mail:Simple MAPI.

Comment 3

[Andrew Schultz]

==> Core
(you'll want to re-request a new blocking flag. blocking-thunderbird2, I guess)

Comment 4

[Christian Franke]

At least the nsMapiRegistry.* modules are only used by SM.
(http://lxr.mozilla.org/seamonkey/source/mailnews/mapi/mapihook/src/)
So I don't know whether this affects TB also.
==> Request blocking 1.8.1.2 only (does this request blocking SM 1.1 ?)

As the bug affects all apps using MAPI, the summary should probably be more general (and include "[regression]") to avoid dups.

Comment 5

[Christian Franke]

This is IMO a dup of Bug 364675 (already confirmed).

Comment 7

[Robert Kaiser]

Christian: If you don't know if it affects Thunderbird, best is to test if it does. If mapiDll is the problem as you assume in comment #1 then it probably affects both SeaMonkey and Thunderbird, I guess.

It would probably be a good idea to check bonsai for changes in MAPI code between 1.0 and 1.1 and/or find the regression range so that we can find out the suspect change(s).

This would be nice to have fixed by SeaMonkey 1.1.1 but as long as no suspect changes are known, it will be hard to find someone who can fix it.

(Confirmed by dupe, the other one was duped to this one, as this one here is probably the right component and the older bug report)

Comment 8

[Bruno 'Aqualon' Escherl]

Looking at the changes in bonsai, only bug 353906 can be the reason for this regression.

Comment 9

[Christian Franke]

(In reply to comment #8)
> Looking at the changes in bonsai, only bug 353906 can be the reason for this
> regression.

Yes, probably.

Tracing MAPILogon() on assembly level, I found that ::CoCreateInstance() for MapiProxy.dll failed.

Steps to Reproduce:
1. Uninstall SM
2. Install SM 1.1b, do NOT open Mail window
3. Examine registry key
   HKCR\Interface\{6EDCD38E-8861-11D5-A3DD-00B0D0F3BAA7}
4. Open Mail, confirm to make SM the default mail app.
5. Repeat step 3.

Observed:
Key removed during step 4, so MapiProxy.dll no longer registered

Expected:
Key should not be removed.

Hotfix:
Go to installation dir and run:
  regsvr32 MapiProxy.dll

Now MAPI works again when SM is running. Autostart does still not work.

Comment 10

[Worcester12345]

(In reply to comment #4)
...
> ==> Request blocking 1.8.1.2 only (does this request blocking SM 1.1 ?)
> 
> As the bug affects all apps using MAPI, the summary should probably be more
> general (and include "[regression]") to avoid dups.


regression key word also

Comment 11

[Christian Franke]

Attachment: Registry file to fix missing startup on MAPI call issue

If MAPI works only when SM is already running, edit the install path in this file and apply the file with regedit.

It adds the entries which should have been added by RegisterServer().
http://lxr.mozilla.org/seamonkey/source/mailnews/mapi/mapihook/src/Registry.cpp#223

Apparently, this function is never called by nsWindowsShellService::setDefaultMail()
(Hmm... the RegisterServer() call is enclosed in #ifndef __MINGW32__ ;-)

Hope this helps.

Comment 12

[Christian Franke]

Attachment: Patch for nsMapiRegistryUtils.cpp

The regression was actually introduced by attachment 240565 [details] [diff] [review] from bug 353906:
nsMapiRegistryUtils::setDefaultMailClient() calls UnRegisterServer() instead of RegisterServer().

The problem was found by code review and therefore the patch is not tested, sorry.

(I take back my last comment about nsWindowsShellService::setDefaultMail(), it is not used by SM).

The bug should not affect TB.
I would request blocking next SM release, but there is no flag ;-)

Comment 13

[Christian Franke]

Comment on attachment 252159 [details] [diff] [review]
Patch for nsMapiRegistryUtils.cpp

r?mscott

Comment 14

[Scott MacGregor]

Comment on attachment 252159 [details] [diff] [review]
Patch for nsMapiRegistryUtils.cpp

good catch!

Comment 15

[Frank Wein [:mcsmurf]]

Christian: Do you need help landing this patch?

Comment 16

[Christian Franke]

(In reply to comment #15)
> Christian: Do you need help landing this patch?

Yes, I don't have checkin rights and I'm not sure which approval*? request is appropriate.

Comment 17

[Tobias Fischer]

Trunk is also affected from this Bug. Would be good to get the Checkin for
Christians Patch into Trunk frist, than ask for Approval for 1.8-Branch too. 

If this goes into Trunk first, I will take a look on the first Builds including
the patch. 

Comment 18

[Christian Franke]

(In reply to comment #17)
> Trunk is also affected from this Bug.

HEAD revision (1.32) is IMO OK, it calls RegisterServer():
http://lxr.mozilla.org/seamonkey/source/mailnews/mapi/mapihook/src/nsMapiRegistryUtils.cpp#1033

This module is no longer used by TB on both Trunk and 1.8 Branch.
This bug only affects SM on 1.8 Branch.

Comment 19

[Andrew Schultz]

Comment on attachment 252159 [details] [diff] [review]
Patch for nsMapiRegistryUtils.cpp

hmm, why does this need TB approval?
http://mxr.mozilla.org/mozilla1.8/source/mailnews/mapi/mapihook/src/Makefile.in#100

Comment 20

[Scott MacGregor]

Comment on attachment 252159 [details] [diff] [review]
Patch for nsMapiRegistryUtils.cpp

approving for the branch (I can't se the 1.8.1.2 flag, but i can set the thunderbird flag) since this is a mailnews only change.

Comment 21

[Scott MacGregor]

clearing the blocking flag, I approved the patch for the branch.

Comment 22

[[e-mail]]

Fix checked in.

Comment 23

[Tobias Fischer]

(In reply to comment #18)
> (In reply to comment #17)
> > Trunk is also affected from this Bug.
[...]
> This module is no longer used by TB on both Trunk and 1.8 Branch.
> This bug only affects SM on 1.8 Branch.
> 
Hmm, are you sure? I have tested SM 1.1 Build 20070126 and verified, that the Bug was fixed for the Branch, but neither sendto:, nor mailto: Protocols were working in SeaMonkey Trunk-Builds. 
I think that SeaMonkey-trunk was affected too, and need the patch. 

Comment 24

[[e-mail]]

Well, not that patch, because that error doesn't exist on the trunk.

Comment 25

[Tobias Fischer]

Well, I am not very personal to lxr and reading Code, but when I understand right, I have to file a new Bug for the Trunk?

Comment 26

[[e-mail]]

Assuming that nobody else has, then yes; this one seems to be branch-only.

Comment 28

[Igor Velkov]

Attachment: error trying send file from microsoft visio

Now i made deinstall of seamonkey; set outlook as defaukt mail program, and installed Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070131 SeaMonkey/1.5a.
Then I made it as default system mailer, but as early bug active:
1. when I select file in windows explorer, then press send to->mail recipient menu, does nothing;
2. when I choose "file->send by mail as attachement in microsoft visio 2003, system shows window (look to attachement)

I propose this bug have to be reopened.

Comment 29

[Igor Velkov]

Attachment: second error window trying send file from microsoft visio

Comment 30

[Igor Velkov]

Attachment: error trying send file from OpenOffice 2.1

sending from OpenOffice 2.1 all the same.

Comment 31

[Tobias Fischer]

(In reply to comment #26)
> Assuming that nobody else has, then yes; this one seems to be branch-only.
> 
I have filed Bug 368952 for Mapi-Linkage issue in SM-Trunk-Builds. 

Comment 33

[brian lehrhoff]

having loaded 1.1.1 and blindly tried the mapi ... IT WORKS!

thanks to all who persevered with such a seemingly simple bug.  and now, after all these years of using moz, i feel like one of the family :)

Comment 34

[Scott MacGregor]

adding a keyword.

Comment 35

[Mirek]

Reopening (but I cannot find the proper ticker in the new Bugzilla interface to really reopen.... :-(  ).

Reason:
Well, the bug does not seem to be fully fixed. When Mozilla (SM1.1.1) is running, no problem, fix is OK. However, without Mozilla running, it still does not work. E.g., the context file menu "Send to / Mail recipient" does not start Mozilla and no action is actually performed. Invoking in the Word (File/SendTo/MailRecipient) results in the old infamous cryptic message...

Previously, before this bug, Mozilla was started at these instances an compose message window has appeared. The workaround still has to be applied manually.

Comment 36

[brian lehrhoff]

That's an easy fix.  Moz should always be running.

I guess we reopen this.  At least it's not as critical as it was.

Comment 37

[Frank Wein [:mcsmurf]]

Do me a favor: File a new bug and mention the bug # here? It would be rather confusing if the remaining issue will be mixed with the old issue in one bug...

Comment 38

[Mirek]

Well, I do not think it wise to file a new bug, as this bug was about all issues caused by this MAPI regression. For example, Bug 364675 (see above), is marked as dupe of this one - and deals only with the issue in my Comment #35 . Filing a new bug would require to re-assess all old duplicates and would make the bug triaging more confusing.

Comment 39

[Robert Kaiser]

Is this still happening with 1.1.2?

Comment 40

[Bruno 'Aqualon' Escherl]

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2, doesn't matter if SeaMonkey is already running or isn't running.

Comment 41

[Robert Kaiser]

OK, let's re-mark it as FIXED then.

If such an issue comes up again for anyone else, please file a NEW bug on that.

Comment 42

[Mirek]

(In reply to comment #39)
> Is this still happening with 1.1.2?
> 

Yes, same problem, no change. Seamonkey has to be running in order to use context-based "send-to". Please note that Seamonkey has to be completely off-loaded from the memory, so you have to have Quick-launch feature disabled.