102392 - Simple MAPI: SMAPI fails to send a doc after multiple sends

Status: VERIFIED FIXED

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

Description

[Trix Supremo]

If you close Mozilla after a successful send and then attempt to send another
document, SMAPI fails to send the document.

DIRECTIONS:
1. Launch MSWord and successfully send a doc.(assume Mozilla Mail is default).
2. Now close Mozilla.
3. While MSWord is still open, attempt to send another doc.

ACTUAL:
Mozilla launches but email client fails to launch.

EXPECTED:
Mozilla's Compose window should be displayed allowing the send of that doc.

Comment 1

[Jaime Rodriguez, Jr.]

Is this a requirement for this drop of Partial Simple MAPI (Bug 102570)? If it 
is, it needs to be marked nsbranch+.

Comment 2

[Jaime Rodriguez, Jr.]

Should we mark this one as nsbranch-, so that we can track it for the next release?

Comment 3

[Scott MacGregor]

Nominating for the branch. This could be something worth investigating I think.
A dup of this bug was also filed by Antonio in 103015 so I think it's easy to be
in a scenario where you try to send multiple documents from the same app in the
same session.

Comment 4

[Scott MacGregor]

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

Comment 5

[Rajiv Dayal]

This is a MS Word specific problem. Also this happens not when you try to send
multiple documents from the same app in the same session, but when u send
a/multiple document(s) and then close Mozilla and try to send again without
closing the app (MS Word). If you close MS Word and start again it works fine or
if u send multiple docs without closing Mozilla it works fine.

However, still looking to resolve why it happens in MS Word.

Comment 6

[Tiantian Kong]

Reassign to Krishna

Comment 7

[Jaime Rodriguez, Jr.]

Marking ETA as 10.10 per PDT Simple MAPI Update.

Comment 8

[Rajiv Dayal]

Attachment: patch with the fix for this problem

Comment 9

[Rajiv Dayal]

Hi Scott and Doug,

can u please r and sr the patch above. It has changes in the way the MS COM
objects for MAPI support interface are maintained in the mapi32.dll.

thanks,

- rajiv.

Comment 10

[Rajiv Dayal]

Hi Scott, wouldn't ur fix for 102821 will in a way provide solution for this
problem too, since u start mozilla in non UI mode / MAPI mode the user would not
exit Mozilla. 

This bug is about the problem when the user does send from MAPI app (MS Word)
and then closes Mozilla and then without closing MS Word does send again. Yes
this problem will still happen after 102821 if the user exits by right clicking
the Mozilla icon from the Windows taskbar.

Comment 11

[Scott MacGregor]

good point rajiv, my fix for 102821 may reduce the severity of this fix since
netscape won't be exiting until the last mapi session logs off. Unless the user
manually quits mozilla. Should we test the fix in 102821 out in tomorrow's
builds and see if it hides the problem enough? Maybe we won't need this patch
too for the branch? Or do you think the user exiting the app may be a common
enough occurrence that we should still take this patch to make sure the session
is valid? 

Comment 12

[Krishna Mohan]

The fix for 102821 may not work with Power Point and Word Pad but work with 
Word and Excel.  Power Point is calling Logoff once the SendMail is done.  Word 
Pad is calling SendMail directly, which will open calls to temporary 
Logon/Logoff.

Comment 13

[Krishna Mohan]

Multiple send is working fine with Word, Excel, Power Point and Word Pad.

Comment 14

[Scott MacGregor]

Comment on attachment 52674 [details] [diff] [review]
patch with the fix for this problem

sr=mscott

Comment 15

[Doug Turner (:dougt)]

In nsMAPIConfiguration::IsSessionValid, instead of calling Get() to check the
exists of an item in the hash table, call Exists().  In fact, this hole function
could be reduced to:

{
  nsAutoLock lock(m_Lock);
  nsPRUintKey sessionKey(aSessionID);
  return m_SessionMap->Exists(&sessionKey)
}


In nsMapiImp::IsValidSession

+    if (pConfig != nsnull && pConfig->IsSessionValid(aSession))

do this instead

+    if (pConfig && pConfig->IsSessionValid(aSession))

I do not see the need for nsMapiImp::IsValid()?  Do we really nee it?

Do you really want to return TRUE CoCreateInstance(CLSID_nsMapiImp...) fails?

Also, I am not quite sure I understand the refcounting going on here. 
CreateInstance returns an addref'ed aRetValue.  If successful, we pass that
value to TlsSetValue which does not addref.  Then we call release on aRetValue.
 And we return this value.  seams to me, that we have two unowned references:
one returned by InitMozillaReference and one in the tls slot.  What am I missing?
Also, what is the ownership module of tId?  Is it ever release or do we just
leak it during shutdown?


Lastly, and much more importantly that any of my comments.  How have we tested
this to ensure that there are no regressions?  

Comment 16

[Jaime Rodriguez, Jr.]

pls check this into the branch - PDT+, pending review and another sr from mscott.

Comment 17

[Krishna Mohan]

Attachment: Implemented review comments from dougt

Comment 18

[Doug Turner (:dougt)]

Comment on attachment 52856 [details] [diff] [review]
Implemented review comments from dougt

no need to initialize retValue to PR_FALSE, but that is a nit.

Comment 19

[Scott MacGregor]

Comment on attachment 52856 [details] [diff] [review]
Implemented review comments from dougt

sr=mscott

Comment 20

[Scott MacGregor]

I think PDT already approved this for check in yesterday. So you should be able
to check this in right now instead of waiting for PDT approval. it's already a plus.

Comment 21

[Krishna Mohan]

I checked in this.

Comment 22

[lchiang]

Should this be marked fixed so it can get on verification radar or are you going
to wait for checkin to the trunk (which may take longer since Simple MAPI is not
on trunk yet)?

Comment 23

[Tiantian Kong]

Checked into 0.9.4 branch.

Comment 24

[Trix Supremo]

verified on 2001-10-12-05-0.9.4