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.

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.

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

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;

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.

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.

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.

doh! that's right.

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

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.

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

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.

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?

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.

This will not be in MachV.

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.

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

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? ;)

removed jhooker from cc: list

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.

dup, fixed (except for the SMTP: issue)

should be fixed in trunk builds now.