102821 - Browser page started up when I initiate a simple MAPI transaction

Status: VERIFIED FIXED

(MailNews Core :: Simple MAPI, defect)

Description

[Scott MacGregor]

Just installed the test build on my machine. 

On my desktop I click on an icon and selected: "Send To Mail Recipients".
(Assume mozilla/netscape is NOT running)

1) Profile manager came up. I expected that.
2) Compose window came up. I expected that.
3) Then a browser window came up! Didn't expect that. 

Shouldn't a mapi transaction just bring up the compose window? Then after the
message is sent, wouldn't the app exit? Or do we intentionally leave a browser
window open after the transaction? Just wondering what the expected behavior is.

Comment 1

[Scott MacGregor]

This may help the bug fixer, it's possible to invoke mozilla with a "-compose"
extension. This causes us to bring up just a compose window and when you hit
send, that compose window will go away and we'll exit the app. Maybe this bug
can be fixed just by trying to use -compose when starting up mozilla.

Comment 2

[esther]

Not sure if this is a different bug, but here is another scenario.  
With MAPI on and using mozilla as the default mail client, if the profile that
is selected doesn't have a mail account, we get a User Name and Password dialog.
 This dialog comes with the Browser, but it's not a mail password dialog.  We
would expect to be brought to the Mail Compose window, followed by the Account
Wizard dialog for creating a Mail Account.  This is how it works independent of
MAPI.  If this bug is fixed to launch using -compose as Scott stated, then I
think we might see what were asking for.  

Comment 3

[Scott MacGregor]

nominating for the branch. This is a usability issue and it prevents mozilla
from exiting after the send is complete because the browser window is still there.

Comment 4

[Tiantian Kong]

Reassign to Rajiv.

Comment 5

[Rajiv Dayal]

Mozilla exe is registered as an MS COM component. If Mozilla is not already
running, when a MAPI App makes a MAPI call MS COM brings up Mozilla. We can
change the registration with a -compose parameter but this will bring up 2
Compose windows one by MS COM and another by SendMail. The true solution to all
this is that we have a parameter in Mozilla to start it in server / no UI mode,
however that cannot be done within the time frame for eMojo as already discussed
in PDT a few days back when we modified to not use the turbo mode.

Comment 6

[Scott MacGregor]

plussing for the branch and re-assigning to me. I think I've got a total HACK
for the branch that works. I can't land it on the trunk though. We'll have to
modify the patch for the trunk. drivers will never let me check in this hack =).

Posting the diffs.

Comment 7

[Scott MacGregor]

Attachment: potential hack fix for the branch

Comment 8

[Scott MacGregor]

Okay here are the problems this patch solves:
1) If mozilla isn't already started, we now don't bring up a browser window.
Instead we bring up the auth dialog (which is going away) followed by a compose
window. If you then send the message, mozilla exits. However we only exit if the
mapi client logged off that session.

2) Same scenario as (1) but before sending the message and dismissing the
compose window, I initiate another mapi session from another application. Now
you'll have 2 compose windows up. Mozilla won't exit until both of these dialogs
have gone away.

3) If mozilla is already running, we won't exit.

RISKS:
1) Part of the patch makes sure we don't exit mozilla until all the mapi
sessions have logged off (and we don't have anymore windows open). In theory if
a mapi application for some reason did not log off and they never do, then we
could get in a state where the mozilla.exe process never exits even though you
don't have any windows showing. This is always bad. 

The only way to remove that risk is to decide ahead of time that each mapi
session should always start mozilla (getting the profile manager, etc) and then
exits after the send is over. Subsequent mapi sends on the same mapi session
would cause mozilla to get started up again. 

In other words, we'd have to agree on that behavior IF we wanted to reduce the
risk of my patch. My patch right now is "smart" enough to not shut down mozilla
until all mapi sessions have been logged off.

Comment 9

[Scott MacGregor]

additional risks:

1) turbo impact?
2) blind send, not sure if that's going to be effected by this new behavior or
not. I don't think it will be but I don't have an app that uses blind send to
test against.

Comment 10

[Scott MacGregor]

btw, this patch would not go into the trunk. For this to go into the trunk the
hacked up logic I added to nsAppRunner.cpp would need to get moved to a new
class in the mapi code. This class would support command line handling for mapi
(nsICommandLineHandler).... 

Comment 11

[Scott MacGregor]

adding a dependency to 103172. I need to adjust my patch a little bit once Rajiv
removes the mapi auth dialog. A couple lines of code are going to move to a new
place once his patch gets checked in.

Comment 12

[Jaime Rodriguez, Jr.]

pls check this into the branch - PDT+, assuming we get the reviews.

Comment 13

[Rajiv Dayal]

instead of defining a command line parameter 'MAPIStartUp' what if we define a
generic parameter called 'StartWithoutUI' or something and use that to register
Mozilla as MS COM component for MAPI support ?

Comment 14

[Scott MacGregor]

Attachment: new fix which merges in with rajiv's change to remove the auth dialog

Comment 15

[Scott MacGregor]

this new patch incorporates the fact that rajiv removed the auth dialog so I
don't have to force mozilla to not exit when the last window is closed before we
show the auth login. 

Now the patch just forces mozilla not to exit when the last window is closed the
first mapi session that gets registered and we unset that flag after the last
mapi session has been unregistered. 

Searching for r and sr tonight so I can get this into the branch.

Rajiv, I didn't make my hack for the branch generic (with regards to making a
new -noui command line) because I'd be lying. This hack really isn't a -no ui
type mode because it requires you to hack in somewhere else code to keep the app
from not terminating after the last window has closed. If I put in a -noui
(instead of using -MAPIStartUp) then people might think we support a no ui mode
when we really don't unless you have corresponding code in your component which
does the right thing. 

For the trunk, I'll file a spin off bug for integrating this correctly. That
could come in two flavors:
1) Some one properly implementing a -noui mode (separate from turbo)
2) (the one I'm in favor of) having simple mapi implement it's own command line
handler to handle -MAPIStartup. Inside that command line handler, we'd have the
following snippet of code:
    // put us in server mode...
    nsCOMPtr<nsIAppShellService> appShell = do_GetService(
"@mozilla.org/appshell/appShellService;1", &rv );
    if ( NS_SUCCEEDED( rv ) ) 
    {
       nsCOMPtr<nsINativeAppSupport> native;
       rv = appShell->GetNativeAppSupport( getter_AddRefs( native ) );
       if ( NS_SUCCEEDED( rv ) )
       {
         native->SetShouldShowUI(PR_FALSE);
         return NS_OK;
       }
    }

But that can wait for the trunk.

Comment 16

[(not reading, please use [e-mail] instead)]

Comment on attachment 52661 [details] [diff] [review]
new fix which merges in with rajiv's change  to remove the auth dialog

sr=sspitzer (for the branch)

Comment 17

[Scott MacGregor]

filed spin off bug #103785 for having mapi properly implement a command line
handler service to do the code that I added to nsAppRunner.cpp. Please don't
land my nsAppRunner.cpp patch on the trunk.

Comment 18

[David :Bienvenu]

Comment on attachment 52661 [details] [diff] [review]
new fix which merges in with rajiv's change  to remove the auth dialog

r=bienvenu, for branch only

Comment 19

[Scott MacGregor]

fixed on the branch. 

qa please see my testing comments above which describe the desired behavior and
things to look for when testing. Also, please test silent send to make sure that
works. I didn't test that and I'm worried mozilla may not exit in that scenario.

Comment 20

[Rajiv Dayal]

Trix can u please test the Blind send for this fix using the test app u have.

Comment 21

[Krishna Mohan]

Mozilla is running even after mapi session count have come down to 0.  I tested 
it with latest 094 branch and tested with MS-WORD, MS-EXCEL.  But when tested 
with Power Point and Word Pad it is working fine.  To reproduce follow the steps 
below.

1. Open MS-WORD/MS-EXCEL.
2. Choose File->SendTo->Mail Recipient
3. Composer comes up.  Send the mail.
4. Quit MS-WORD/MS-EXCEL.
5. Open the Task Manager.  You will see mozilla running.

Comment 22

[Scott MacGregor]

do we know for sure that word and excel are logging off the session when they
are done?

Comment 23

[Scott MacGregor]

Oh I see....word or excel is probably logging off a while after we've closed the
compose window. So setting "exit after the last window closes" back to true when
we log off the mapi session for word and excel isn't going to do anything
because we don't have a last window that just closed or is about to close. 

In the case of power point and word pad, they log off after sending the message
instead of waiting until the user closes the app (app being power point, word
pad, etc).

I think this means we need to choose the behavior we talked about in PDT where
we'll always shut down after each send if that was the last open window. So we
won't keep mozilla up when a mapi session is in progress.

This in turn means that we'll have to take Krishna's / Rajiv's fix in 102392
which checks for the validity of a mapi session before re-using it.

Comment 24

[Krishna Mohan]

>>I think this means we need to choose the behavior we talked about in PDT where
>>we'll always shut down after each send if that was the last open window. So we
>>won't keep mozilla up when a mapi session is in progress.

mscott : Are you fixing this?

Comment 25

[Scott MacGregor]

yes.

Comment 26

[Scott MacGregor]

I just checked in the code to remove the mapi code I added for keeping mozilla
runnning until the last mapi session logs off. Now the behavior is the fall back
behavior I described here yesterday:

The only way to remove that risk is to decide ahead of time that each mapi
session should always start mozilla (getting the profile manager, etc) and then
exits after the send is over. Subsequent mapi sends on the same mapi session
would cause mozilla to get started up again. 

Comment 27

[Rajiv Dayal]

Well we need to decide here whether we can take the performance hit because of
this. There could be a custom app which generates many many e-mails in a single
session (eg : an automated app sending billing statement every 1st of the
month). In this case it will restart mozilla for each send.

Also if we do take this decision there is no need for any session management
which boils down that we do nothing in Logon/Logoff, and during each send just
make the call to the send api of our mapi support interface which will bring up
mozilla since it is registered as the COM component for this interface.

Comment 28

[Krishna Mohan]

Attachment: Implemented review comments from dougt

Comment 29

[Krishna Mohan]

Forget about the patch "Implemented review comments from dougt".  This has to be 
in 102392.

Comment 30

[Scott MacGregor]

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

crossing this patch since it is for another bug.

Comment 31

[Scott MacGregor]

I think we have to take this performance cost. Esp if the trade off is having a
browser window come up and then not having the app properly exit after you send
the message. I suspect for 95% of the users that's going to be there scenario.
Or they'll already have mozilla running so the point will be moot. So the
question is what happens for automated apps making many sends during the same
mapi session. Well if it's automated they aren't going to notice the extra time
it takes for mozilla to start up for each one. If they do care, then they can
just leave mozilla running before they kick off the automated app then we won't
quit on them. So I think there's a clear work around for automated apps were
this could be a problem.

Eventually your idea of possibly manually sending a quit/exit command after the
last mapi session has logged off may be the right way to go. But I started to
think about that last night and feel it's probably too risky to try doing for
this release. But that's just my two cents. It would be an interesting bug to
file for the next release and to start thinking about how to solve that problem.
What do you think?

Comment 32

[Rajiv Dayal]

Yes i agree that we can look at this in the next release if we have the
workaround  of asking the user to start mozilla and keep it running before
running a custom app which sends many mails in one session.

Comment 33

[Trix Supremo]

verified on 2001-10-12-05-0.9.4