104291 - blind send not working

Status: RESOLVED WORKSFORME

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

Description

[Rajiv Dayal]

With the current build blind send is not working. Using the test app, blind send
starts mozilla, displays the Profile manager dialog, blind send security dialog
and returns with an error without sending the mail. In case if mozilla is
already running, once on Trix's machine it just hung the app and other times it
just returned without sending the mail.

Comment 1

[Rajiv Dayal]

This has started occuring after we stopped bring up the mozilla window as per
the fix for bug # 102821. The fix checks the commandline args and sets the
SetShouldShowUI as FALSE which does not display the browser window. Thus during
the blind send when the security warning dialog is closed, mozilla exits (since
that would be the last window displayed for the operation). Also in case if the
security warning dialog is not displayed it exits after the Profile manager
dialog is closed (considering that to be the last window). Thus the mail is
never sent.

Please find below the proposed fix that sets the AppShell API
SetQuitOnLastWindowClosing to false as soon as blind send starts and sets it
back to true after blind send is complete. This would make sure that mozilla
exits only after the blind send is complete.

Comment 2

[Rajiv Dayal]

Attachment: proposed fix for blind send

Comment 3

[Jaime Rodriguez, Jr.]

Let's get the sr/r=, and have this in our pocket if needed.

Comment 4

[Rajiv Dayal]

Attachment: updated patch resetting flag before all returns

Comment 5

[Scott MacGregor]

Comment on attachment 53190 [details] [diff] [review]
updated patch resetting flag before all returns

rajiv, wouldn't it be easier  just to 
1) move the isBlindSendAollowed up before we set quit on last window to false.

2) Instead of adding a bunch of if clauses reseetting the quot on last window closing every time we return, we could re-write the method to only return at the bottom. 

such that instead of several of the following:
if (NS_FAILED(rv)))
{
 exit code stuff
}
we could just do:
if (NS_SUCCEEDED(rv))
{

  continue to do more useful stuff

}

then at the end
SetQuitOnLastWindowClosing(PR_TRUE);
return rv;

Comment 6

[Scott MacGregor]

scratch that 2nd comment because that will cause a lot of white space changes
that make the patch a little bigger for PDT to look at. And they won't like
that. Although when you move it to the trunk it might be an interesting thing to
consider.

Comment 7

[Rajiv Dayal]

I cannot do the (1) above since the security warning dialog is displayed and
closed in the isBlindSendAllowed function and so exit 'might' get called before
this function returns. Thus it is safer to call SetQuitOnLastWindowClosing to
False before the isBlindSendAllowed call which will guarantee that mozilla will
not exit before blind send completion.

Comment 8

[Rajiv Dayal]

Scott, I have made the changes as per 2) in ur suggestions above but will use
that for check in to the trunk as per ur next suggestion.

Comment 9

[Scott MacGregor]

doh! that's right.

Comment 10

[Jaime Rodriguez, Jr.]

pls bring this back up, if it found to be a stop ship by an enterprise customer.

Comment 11

[Rajiv Dayal]

Please find below the updated patch with changes to return the function from one
place. Also I have removed the usage of hidden window when calling
nsIMsgCompose::Initialize, nsIMsgCompose uses it as a parent for the Progress
dialog and other UI displayed. Since this is a blind send with no UI there is no
need for it.

Hi JF and Scott, can u please review this patch for trunk landing ?

thanks.

Comment 12

[Rajiv Dayal]

Attachment: updated patch return at one place, removed usage of hiddenWindow

Comment 13

[Rajiv Dayal]

Please ignore this patch, am in process of putting up another patch.

Comment 14

[Rajiv Dayal]

The fix for this bug depends on the fix for bug # 103785. If we put a fix there
to not restart Mozilla for each Send call and rather keep Mozilla till a MAPI
session  is not logged out, it will also fix this problem. The problem faced
here was since the security warning dialog was assumed to be the last window and
when it closed Mozilla was exiting. This will now not happen if we decide to
keep Mozilla running for the complete session as part of the fix for bug #103785.

Comment 15

[scottputterman]

Rajiv, is there work that has to be done for this if we just take what was on
the branch last time and apply to the branch for this time?

Comment 16

[Rajiv Dayal]

We need to fix this when we fix 103785 for the branch for our next release. For
the trunk this depends on 56654. Adding dependencies and changes milestone as
per 103785.

Comment 17

[Jaime Rodriguez, Jr.]

This will not be in MachV.

Comment 18

[Michael Buckland]

Adding jaime and jeff to cc list.

Jeff, we discussed this in ADT today.  Given the current number of bugs and thin
resources, we must defer this bug unless you can supply concrete data that it
affects a large number of users in a serious manner.  We wanted to do the due
dilligence and make sure you are aware of the action we took on this bug, and
have the opportunity to respond if needed.

Comment 19

[Jeff Hooker]

removed tiantian from cc (bad alias; sends mail to jhooker)

Comment 20

[Joe Konecny]

Just wanted to add my 2 cents...

This problem is a show stopper.  I was going nuts trying to solve this with our
apps.  Reading about this bug effectively ends our Mozilla rollout.  It's back to
outlook till then.  I really, really love Mozilla though!  Too bad!  That's
about 50 users!   Is that enough?  ;)

Comment 21

[Jeff Hooker]

removed jhooker from cc: list

Comment 22

[Doug MacLean]

See my comments on bug 221673, comment 5.  This is related, because even when
THIS issue is fixed, the blind send wouldn't work anyway due to the "SMTP:" not
being stripped from the message addressees.

Comment 23

[David :Bienvenu]

dup, fixed (except for the SMTP: issue)

Comment 24

[David :Bienvenu]

should be fixed in trunk builds now.