Overview: A variety of problems occur when using Mapi with Quick Launch. 1. On my WinMe system using branch build 2002-07-01, Quick Launch on I: - was able to send 2 separate Word documents using mapi - on the third attempt it reported an error with the address book on the exchange server (why it referenced an exchange server I don't know). - 4th attempt it reported the same error - Turned Quick Launch off and then Mapi worked - Turned Quick Launch back on and it successfully sent a word document - Able to send a second and third time - Interesting the Wordpad does not work at all 2. Win2k: a. Gaytri's Win2k system, after turning Quick Launch on it failed. After turning Quick Launch off then it was successful. b. Stephen's Win2k system experienced similar problems when trying to send a Power Point Presentation. With Quick Launch and Mapi turned on, if it worked at all, then it opened the Browser but not the Compose window.
Marking nsbeta1 so that Mapi will work with Quick Launch.
** The problem occurs with Multilple Profiles with Quick Launch and Mapi enabled** Steps to reproduce: 1. Make sure that you have 2 profiles 2. In one profile enable Mapi and Quick Launch 3. Close the app 4. Open Word, File|Send a document Actual Results: No Netscape window opens. Expected Results: I would expect the Profile Manager to appear. Once a profile was selected then it would automatically display a Compose window for the default mail account. Additional Information: - It is ok using one profile with Quick Launch and Mapi enabled. - It is also ok with multiple profiles with Mapi enabled (but Quick Launch disabled) - The problem with Wordpad is logged in a different bug. Note to QA: When verifying this bug try different applications such as Word, Excel and PowerPoint.
Rajiv, Bill Law and/or Steve Morse should be able to help you fix this.
I'll take this one. It's a quicklaunch problem.
OK, I have a patch that fixes the problem. In testing it, I observed another problem. Namely if you are not running the browser (not even in turbo mode) and you issue a MAPI command from an app (i.e., WORD: file->send-document), two windows will open -- one for the composer as expected, and one for the browser itself. This occurs for both single profiles and multiple profiles. I backed out the patch and it still occurs. So this has nothing to do with turbo nor with multiple profiles, but is a MAPI bug. And it has nothing to do with the current bug report. Is there a bug report open on that or should I file it?
Created attachment 90245 [details] [diff] [review] Allows MAPI to work with turbo with multiple profiles
In fact there is no need to even check for the MAPIStartup commandline argument since that was put in there so that no additional window is opened for MAPI and another part of code did nsINativeAppSupport::SetShouldShowUI(PR_FALSE) in the 0.94 branch for N6.2 release. However that ..ShowUI code never landed on trunk since the right thing to do was to implement a Command line handler for MAPI but the nsICmdLineHandler did not provide support for arbitrary processing as required in this case. And there were lots of request to rewrite the entire nsICmdLineHandler interface rather than enhance it to support arbitrary processing. And this is the same reason why you see a browser window opened up when MAPI is called. Anyway since there doesnot exist code to supress the browser window from coming up when MAPI call is made, there is no point in even checking for the MAPI Startup Arg. The EnsureProfile statement that is anyway in the HandleRequest function will display the profile selection dialog in case if either Mozilla is not running or running in Quick Launch mode. Steve, I have attached a new patch for this, hope that is fine. I have tested this patch with multiple profiles, single profile in Quick Launch as well as otherwise.
Created attachment 90265 [details] [diff] [review] patch to not check for MAPIStartup arg and return
Rajiv, Your patch was the very first thing that I tried. It works but it opens up two windows -- a composer window and a browser window. That's why I rejected it. With my patch I don't get the double windows when mozilla is running (with or without any open windows). I get the double window only when mozilla is not running. With your patch I get the double windows in all cases -- whether mozilla is running or not.
That is surprising, I do not see it open another browser window if a browser window is already open. But I do see the browser window open up if Mozilla is running in turbo mode without any browser window already open. Also reading your comments earlier I thought that is what you see with your patch too so I did not see any advantage in doing the check for MAPIStartup arg.
Comment on attachment 90265 [details] [diff] [review] patch to not check for MAPIStartup arg and return Marking this as obsolete since the earlier patch works better in case if Mozilla is already running in turbo mode without any window open.
From the update of (id=90245): What if u move the check for MAPIStartup arg after the EnsureProfile call ? Besides that r=rdayal.
Let me clarify what I said because it is confusing. All the following is with two profiles. 1. Without any patch: no windows open, no turbo icon: MAPI opens browser and composer windows no windows open, have turbo icon: MAPI does nothing <<this bug>> 2. With my patch ("allows MAPI to work with turbo with multiple profiles") no windows open, no turbo icon: MAPI opens browser and composer windows no windows open, have turbo icon: MAPI opens composer windows 3. With Rajiv's patch ("patch to not check for MAPIStartup arg and return") no windows open, no turbo icon: MAPI opens browser and composer windows no windows open, have turbo icon: MAPI opens browser and composer windows
Comment on attachment 90245 [details] [diff] [review] Allows MAPI to work with turbo with multiple profiles sr=jag
Landed on trunk
trix, can you verify this fix on the trunk. Thx.
looked at it on todays trunk build 2002070913-trunk and it still isn't fixed. already spoke to rajiv about the problem.
my mistake on this verification on trunk build, i used wordpad to test SMAPI and forgot about the bug already documented about SMAPI not working on wordpad. verified on MS WORD, EXCEL, and powerpoint with quicklaunch enabled with multiple profiles and SMAPI is working. marking verified
adding adt1.0.1+. Please get drivers approval before checking into the branch.
please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
verified on branch build 20020711, changing keyword to verified1.0.1