[go: nahoru, domu]

Open Bug 103785 Opened 23 years ago Updated 2 years ago

[TRUNK ONLY] Mapi needs to implement a command handler service

Categories

(MailNews Core :: Simple MAPI, defect)

x86
Windows 2000
defect

Tracking

(Not tracked)

People

(Reporter: mscott, Unassigned)

References

Details

This spun off from 102821 which went into the branch (hopefully) tonight. 

Before landing mapi on the trunk, we need to have mapi become a command line
handler capable of handling -MAPIStartup. It then needs to do the following when
invoked:

+    // 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;
+       }
+    }

this will force mozilla to not show any UI when we start it up. Then the mapi
code can bring up a compose window at it's leisure.
Scott: 

Will do after 0.9.4. Thx for checking in bug 102821. 
Priority: -- → P3
Keywords: nsbeta1
Blocks: 104672
Reassign to Rajiv. 
Assignee: tiantian → rdayal
This bug is related to moving the MAPI commandline handler code currently in
nsAppRunner to MAPI code as a fix to bug # 102821. 

Besides doing that we also need to rethink the strategy about it to take care of
the following problems :

-- Mozilla still keeps running in case a failure is returned. This happens
because there is no UI displayed in this case and thus there is no last Window
closing which would lead Mozilla to exit and hence it keeps executing.

-- Mozilla is called each time a MAPI function is called, this could effect
performance of applications making multiple MAPI calls in one session.

As a solution to both of the above what if we call "nsIAppShellService::Quit"
from Logoff if Mozilla was started by a MAPI call. 

Besides bringing up Mozilla in no UI mode when started up for a MAPI call we
would set "nsIAppShellService::SetQuitOnLastWindow" to FALSE which will keep
Mozilla running till the session is alive and will exit only when the session
ends (Quit called from Logoff) irrespective of whether the MAPI call succeeds or
fails.

Target Milestone: --- → mozilla0.9.7
The fix for this bug depends on the bug # 106137. A new XPCOM interface
nsIMAPISupport is defined to bundle the Simple MAPI COM component and XPCOM
Registry component. This interface should be derived from nsICmdLineHandler to
handle the -MAPIStartup commandline argument which would set :-
        nsINativeAppSupport::SetShouldShowUI(PR_FALSE);   and
        nsIAppShellService::SetQuitOnLastWindow (PR_FALSE) ;

And the following code should be added to the msgMapiImp::Logoff :-
        if ( g_bIsMapiStartup )  // or whatever
        {
            nsCOMPtr<nsIAppShellService> appShell = 
do_GetService(@mozilla.org/appshell/appShellService;1", &rv );
            if ( NS_SUCCEEDED(rv) ) 
                 appShell->Quit() ;
        }
The current nsICmdLineHandler is tied to opening a Window using a Chrome URL.
However in this case we bring up Mozilla without any UI and so the
nsICmdLineHandler cannot be used to do what we wish to do here. There is no
method in nsICmdLineHandler which can be implemented here to handle the
-MapiStartup commandline to supress the UI on Mozilla startup. A new bug 108766
has been opened to deal with the extension of nsICmdLineHandler.
Depends on: 108766
Reassign to Krishna.
Assignee: rdayal → kkhandrika
reassigning to rdayal.
Assignee: kkhandrika → rdayal
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Keywords: nsbeta1nsbeta1+
Priority: P3 → P1
Putting in 0.9.9 because I'm not sure when a branch is going to happen.  We'll
fix this when we branch for our next release.  When 56654 gets fixed we can land
this on the trunk.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Blocks: 104291
Target Milestone: mozilla0.9.9 → mozilla1.0
Whiteboard: [ADT1]
Whiteboard: [ADT1] → [ADT1] ETA - 4/16
saari, please explain the adt1 nomination you made for this bug in terms of
number of affected users and severity of the problem.
Looks like one I marked in an ADT session, but I can't remember why we thought
it was adt1. Probably because hanging on shutdown is less than ideal. Looking at
it today I'd say adt2 unless we think there are or will be hordes of mapi users
nsbeta1- per ADT triage as there is no longer a customer for this.
Keywords: nsbeta1+nsbeta1-
Whiteboard: [ADT1] ETA - 4/16 → ETA - 4/16
Whiteboard: ETA - 4/16
removed tiantian from cc (bad alias; sends mail to jhooker)
QA Contact: trix → yulian
QA Contact: yulian → stephend
Product: MailNews → Core
Assignee: rdayal → nobody
Priority: P1 → --
QA Contact: stephend → simple-mapi
Target Milestone: mozilla1.0 → ---
Product: Core → MailNews Core
Sid is that implemented already ? Or is there work that needs to be done ?
(In reply to comment #13)
> Sid is that implemented already ? Or is there work that needs to be done ?

It's been partially implemented in bug 482966, but I don't think this should be closed yet. We still open the main window.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.