Simple MAPI is supported in NS4.x, but not in NS6.x. What is simple MAPI? "Simple MAPI (Microsoft Messaging Application Program Interface) is a set of 12 common API calls which allow an application to send, address, and receive messages. MAPI support can be used to allow non-messaging applications such as spreadsheets and word processors to perform messaging operations." ( From NS 4.x spec ) NS4.x supports these 12 common API calls such that when applications make calls to them, it utilizes messenger to perform the mail tasks. Why we need simple MAPI support in NS6.x: (1) to ensure deployment from enterprise customers. (2) to provide convenience for individual customers. This bug is to track and organize the development effort to enable simple MAPI support in NS6.x. ( NOTE: Full MAPI will not be supported.) Scot, Jussi, Tiantian, Srilatha, Krishna, and Rajiv had a meeting this afternoon, 7/20. Krishna and Srilatha will do a prototype to investigate the scope of work. Once we are clear about the scope of work, we'll have a development plan. We'll meet again next Tuesday, 7/24. Here's a initial to-do list from Krishan: "1. Simple MAPI Interface implementation is tightly integrated with Netscape 4.x code. So, need to check out weather all those functions and data types still exists in 6.x code. 2. Look out for changes in the Simple MAPI specification. 3. Provide Code for all the Simple events; With Shared memory as IPC Channel. 4. Need to check error logging. 5. Need to check Response codes. 6. Little bit of XUL is need to create the Hidden Window." The following people will provide help and consulation. Mail: David Bienvenu ( bienvenu@netscape.com ) Compose window: Jean-Francois Ducarroz ( ducarroz@netscape.com ) address book: Candice Huang ( chuang@netscape.com ) XP toolkit: Daniel Matejka ( danm@netscape.com )

I think we should assign this to Krishna since he will be doin the work. I'm changing the summary since this should work in all mozilla based mail products, not just NS 6.x products.

(1) Added nsEnterprise keyword. (2) Per comments from Krishna and Srilatha, I talked to Mitch Faatz. There may need to be changes for the installation script. (3) Added in the cc list: eClient tech writer ( cwozniak@netscape.com ) , CPD tech writer, ( jatin@netscape.com ) and UI designer ( jglick@netscape.com ). (4) Going to get eClient QA support from Hong.

Copied email from Jonathan Granrose for future reference: "I see both Warner and Time want Simple MAPI support as a high priority. Whatever MAPI support we do (simple or extended), my only request is that we implement it fully and cleanly and fully document it. Since I'm assuming we'll need to include our own mapi DLLs to enable mail access to Netscape from non-Netscape apps, the ability to install or remove those DLLs separately from NS6 would be key as well. The MAPI situation for 4.x was a full on nightmare, especially from a tech support standpoint. Anything we can do to keep that from repeating itself in 6.x would be a big win. Thanks for listening, -j "

Since this won't make it to Mozilla, it's just confusing to have it in bugzilla. I think you should move this bug, as the last bug about MAPI (the bug about implementing it) contributed to some confusion when it became known that it is a Netscape-only feature.

why wouldn't we want MAPI support in mozilla?

hopefully, as much of this code as possible will live in the mozilla tree.

Hakan, you lost me - why won't this be in mozilla? I believe Scott explicitly said it would be in Mozilla.

A few comments about Rajiv's draft: The NS 4.x Simple MAPI dll is a bit flaky. Especially in the handling of messages with attachment and program stability when handling messages with no MIME preamble. I work for a company that has a product which pretty extensively uses the Simple MAPI interface, and I've noticed these problems first-hand with Netscape 4.x. So I agree with the idea of starting from "scratch" FWIW, you can see the SMAPI compliance of 4.x at the following URL: http://developer.netscape.com/docs/manuals/communicator/mapisupp.htm On a Win32 system, the file which handles MAPI is MAPI32.DLL and it's located in the System folder. On a system with IE5 or later, the MAPI32.DLL file is "smart" and does not (and **should not**) need to be overwritten. When a user selects the default mail client in the control panel, all calls to MAPI32.DLL get "forwarded" on to the actual client's MAPI dll as specified by the DLLPath registry entry. For example. If a user selects "Mozilla" to be the default mail client in the control panel, HKLM\Software\Clients\Mail\(Default) is set to "Mozilla" When a simple MAPI call is placed, MAPI32.DLL (the Microsoft one) will take a look at the registry value: HKLM\Software\Clients\Mail\Mozilla\DLLPath , which may have a value of something like "C:\Program Files\Mozilla\program\mzmapi32.dll" So even though the file MAPI32.DLL in the System folder is the Microsoft-provided one, all of the Simple MAPI calls get transparently sent to the DLL in the registry key above. (mzmapi32.dll) It's as if the MAPI32.DLL in the system folder was the one provided by Mozilla. This works nicely, because no overwriting of DLLs is required! This avoids (all?) of the problems listed in the last section of the proposal labeled "Problems with using Netscape MAPI dll", such as not being to launch Outlook. In cases where the system is an IE4 or earlier system, it's not as clean to set up simple MAPI. The DLLPath registry key is ignored and if a program is to be the default Simple MAPI client, then it must replace the MAPI32.DLL file in the system folder. (backing it up). When the program is uninstalled or specified to not be the default mail client anymore, the original MAPI32.DLL file is restored. I'm not certain what exactly controls what is done "behind the scenes" when the default mail client is changed in the Windows Control panel, though. When changing certain mail clients, it can involve an amount of disk activity, so perhaps the program is replacing the MAPI32.DLL file as necessary. In an IE4 or earlier system, it is possible to get in a situation where a program is the default Mail client but not the default Simple MAPI client. (MAPI32.DLL is the non-smart Microsoft-provided one, but in the control panel the default Mail Client is something else). In this scenario, when a simple MAPI call is made, whichever MAPI32.DLL is in the system folder determines which application responds to it. I guess this was a bit of a ramble, but hopefully somebody will find some of it useful...

I thought this wouldn't be added as it was said in the other (recently fixed) MAPI bugs that they had licensing issues or something, and that it would only go to NS6. Hopefully I was wrong.

I would expect this to be in Mozilla, if not picked up in the Mozilla browser, at least developed in the open source tree. If anyone knows whether we need to clear copyright issues to get any (are there any?) re-used lines of source from the 4.X implementation introduced into Mozilla.org, please let me know asap. Or, if we need to develop in a "clean room", then we need to know that asap as well.

My personal opinion would be that we shouldn't (and possibly, can't) reuse 4.x code in Mozilla. This project is all about rewriting this from scratch. Either way, we should probably contact brendan@mozilla.org regarding this issue. CC brendan

I'd rather see us develop a new implementation and know how to fix the bugs that we'll have, rather than starting with known bad code and trying to fix bugs we couldn't find or fix in the 4.x implementation.

I don't think this is really an issue - On the one hand, the client interfaces are all completely different so the interesting parts are all going to need to be rewritten. And on the other hand, if our 4.x MIME code has problems with mal-formatted documents (I was not able to follow this link - http://developer.netscape.com/docs/manuals/communicator/mapisupp.htm so I can't tell what the actual problem was), then the mozilla MIME code probably has the same problem. (And if anyone dares suggest that we rewrite the MIME code, then they should feel free to go for it! :-) )

We ported a bunch of mail code from 4.x. Of course, it had to be integrated into the new world. I don't see why this should be any different. I think we should reuse what we can reuse and rewrite what we can't and try to get a good implementation done as quickly as possible.

hwaara: this project is not about rewriting everything from scratch, that's just silly. We use NSPR, JS, and other modules that were not rewritten (other than incrementally, as owned, living codebases) from the "Classic" days. What is the problem you're trying to solve here, by cc'ing me? If the MAPI code is crap, then by all means don't use it, but that's not an assessment I can help make right now. If the code is properly licensed, it can be considered by the relevant owners and peers. What is the license? /be

Based on the analysis that we have done (please see the attached draft doc above) it seems like there would be very little that we will be able to reuse from the N4 code base for mapi support. The N4 code is well written however not too much can be beneficially used for our implementation. In fact reusing it might make our implementation for MAPI support in Mozilla more complex and the design not straight forward (please see topic "Approach for MAPI support in Mozilla" in the document attached above).

Here's the link to the Simple MAPI documentation. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mapi/html/_mapi 1book_functions_for_c_and_c_.asp This documentation is viewable from IE. In communicator and mozilla it is displayed as page not found. But if you copy the link location for the API and paste it in the location bar and remove the space in it, then it will be displayed fine.

Our approach for providing MAPI support in Mozilla/Netscape 6.x was to not use any of N4 implementation of mapi32.dll. We had planned to re-design the mapi32.dll that will export and implement the Simple Mail APIs. On being called the new implementation will first check whether mozilla is already running, if not it will invoke mozilla. It will then convert the data passed in as parameters to the Simple Mail APIs to mozilla data structures and then use XPCOM to call the mozilla\mailnews interfaces that provide the messaging functionality. The above will result in the mapi32.dll being mapped and loaded into the process space of the calling application. The invoked mozilla will run as a separate process. Hence the XPCOM call from mapi32.dll to mozilla\mailnews interfaces will be an inter-process call (IPC). However, XPCOM does not support interface calls across processes. Thus the mailnews dll implementing the called interface will be loaded into the calling process by XPCOM. This creates a new data segment and the calls to the mailnews interfaces do not use the data in the invoked mozilla process. The possible solutions to this problem are : 1. Use the existing mapi32.dll implementation in N4 and the same design. The existing mapi32.dll will use Windows Shared memory and SendMessage for IPC to Mozilla. Rewrite the N4 hook part to be part of Mozilla and use mozilla\mailnews interfaces (Please refer to draft analysis and design doc for N4 overall architecture) However, this will have a lot of Windows specific code. 2. Modify the mapi32.dll to use NSPR Shared Memory and NSPR pipes for IPC and re-implement the hook part that will use NSPR IPC and call the mozilla\mailnews interfaces. 3. Use DCOM to take care of the IPC details (this is Windows only feature). Export mozilla\mailnews for required messaging functionality and register mozilla executable as DCOM component. Write the mapi32.dll to call these mozilla\mailnews DCOM interfaces, DCOM will handle the call across process space. 4. Load all the required dlls of mozilla required to be loaded for mozilla\mailnews. We will need to figure out what all mozilla start up dlls needs to be loaded, in what order and in which way so that all initialization is done to access mailnews interfaces and functionality.

see also bug 68702 [RFE] Implement inter-process communication (IPC) in Mozilla

With the help from Doug Turner, David Bienvenu, Jean-Francois Ducarroz, Roger Chickering, our team has made the decision to use the COM technology to handle IPC on 8/6. An updated design doc will soon be attached to this bug. Below is a to-do-list: (1) MAPI32.dll - exposing MAPI interface (make files) - converting MAPI parameters data to be COM compliant - using strings within MAPI32.dll, make them UNICODE. - make decisions for instantiate Mozilla and UI. - make decisions for the cleanup of Mozilla instances. (2) Interfaces for simple MAPI in Mozilla mail news. - defining COM compliant interface API - data conversion from interface data to mailnews/Mozilla data struct. - implement the API using mailnews interaces for logon, logoff, send mail, send document (3) installation & pref management. - register MS COM component for MAPI support (by the installer team) - change/modify registry setting for MAPI dll (by the installer team) (4) integration, testing ( Hong will provide a dedicated QA on 8/13.) (5) For the mailnews part: review by Jean-Francois, super review by David. (6) For the COM part: super review by Doug. Team decided that Krishna and Srilatha will implement the flow from mapi dll to Mozilla mailnews for the logon feature during the next 7 days. Estimated delivery date to QA is 8/15. Meanwhile, Rajiv will investigate the remaining mailnews interfaces for logoff, send mail, and send document. A complete schedule will be made, once Rajiv completed the investigation of the mailnews interfaces.

mass qa assigning all simple MAPI bugs to olgac

*** Bug 11057 has been marked as a duplicate of this bug. ***

Adding old blocking bugs and ccs.

Can you attach the individual source files instead of one big jar file?

Since this is a meta bug for the simple MAPI feature, posting the patch for MAPILogon in bug 95117.

If you don't want to attach each file, what you can do is cvs add your new files (but don't commit them!), then do a cvs diff -uw -N which will show the new files as diffs.

Since cvs add requires write access and neither me or Krishna has it, we created the tar file. Anyway, we have now asked Srilatha in our group to create a patch with all the files in it. She will attach the patch to the Logon bug. Also, Krishna can u please attach any other patches/comments on the MAPILogon bug (or other individual bugs) instead of this major bug for MAPI support. - thanks.

cvs add is a purely local operation - I'm surprised it requires write access.

My first comment is - don't use tabs. It looks like all your files have tabs in them. You should use 2 or 4 space indentation. You can configure msdev to not put tabs in, and you can also use it to reformat all your files to take out the tabs (edit | advanced |format selection) Also, you should use the relevant mozilla conventions when possible (PR_TRUE instead of TRUE, PRBool instead of BOOL, nsCRT::strcmp instead of strcmp. etc). Some of your methods/files probably need to use COM conventions, but any mozilla code, even if it's windows-only, should use mozilla conventions.

as suggested by Chip Clark this is MAPI main bug so i have cut-pasted the comments (by bienvenu 2001-08-23 18:32) from here to the Logon bug (# 95117). we will use that for comments for the Logon code.

it does, there's a red bean tool that lets you get around that nastiness. fwiw cvs add of a directory is _not_ purely local, although that's no justification for the cvs add of a file... cvsdo.pl from http://www.red-bean.com/cvsutils/ (actually it's from their cvs server, but ...) will allow you to add stuff locally w/o manually hacking the CVS/Entries file (which isn't actually hard if you already have an account somewhere so you can steal syntax, but that's kinda catch22).

QA contact over to trix

Copied email below for reference: BIG THANK YOU to Steve for offering and organizing help to the simple MAPI project. Action items from this meeting: 1. mscott: open bugs for unicode conversion and missing attachment 2 [details] [diff] [review]. Rajiv: investigate registration issue for simple MAPI. 3. Sean: Own the bug for installer. 4. Tiantian: notify r and sr the urgency for simple MAPI. 5. Other: see the EXCEL attachment in previous email. 6. Everyone: discuss status about your bugs and AI for simple MAPI, at 4pm meeting tomorrow. ================== Division of labor for simple MAPI ( 9/13, Thursday) --------------------------------------------------- Name bug no. JF 95113 r of send mail,start debug mail news interface for send mail Scott M 99524 deliver the fix for smtp Rajiv/K 95116 start send doc Krishna 95117/95121 continue log on, log off Srilatha 95122 continue pref,implement r & sr comments Sean Su 99526 start installer Trix (QA)91702 start test plan for pref, and send mail, send doc. List of reviewer, super reviewer -------------------------------- name r/ sr bug no. or feature Rajiv r Pref, 95122 Seth sr Pref, 95122 Dan Veditz r log on, log off, 95117/95121 Bill Law r xpfe/bootstrap for log on, off Alec sr xpfe/bootstrap for log on, off JF r send mail, 95113, send doc, 95116 David B sr send mail, 95113, send doc, 95116 Syd r installer, 99526 Dan sr installer, 99526 Expected results by 9/18: (1) checked in code for log on, log off, and pref which has completed r, sr. (2) coding complete for send mail, send doc, installer critical path ( the most uncertainty): (1) Scot's smtp bug, 99524 (2) JF's send mail, 95113 (3) Rajiv's send doc, 95116

Normally I send status to my manager by email everyweek. However, at this stage, a lot of people are interested to receive status update, and suggested me to put it on the meta bug. Therefore you see it here. It may also be helpful to QA to retest and ensure those problems encountered in development really get a robust fix. ( Trix: include test plan for these? ) Update of status as of 9/14: xpfe/bootstrap ( Krishna) --completed r, sr. --submitted a patch that included one change based on sr comment. Waiting for reply from Alec. log on, log off ( Krishna) --done make file changes. To do: --make cpp, header file changes, --submit for second (hopefully last) round of review ( Dan Veditz) COB today --work on r comments, --submit to sr (Doug T) preference bug: 95122( Srilatha) --waiting for one more feedback from Seth's sr comment ( pref's UI part ) To do: --registration of COM component --save previous app as default mail client --submit to Rajiv for r COB today --then sr to Seth. send mail bug: 95113 (Rajiv, Scot, JF): --Completed investigation about the registration of COM component. --completed send attachment as nsiFileObject. --completed use default char set for email body. --Scot has fixed bug 99524!!! To d: --deal with failure of non-unicode call from other app to simple MAPI. --sort out the memory corruption problem.

nsbranch+

Simple MAPI Status (w/e 9/17): Every to do item on 9/14 has been completed. All critical items last week has been fixed. Cheers to the simple MAPI team!!! New Critical items ( items with the most uncertainty)as of today: (1) review, super review comments ( especially for pref, as the UI needs to check in today. Seth??) (2) testing feedback. (3) integration of all features. Producing dll, Mozilla exe changes, etc. ( Target completion: COB 9/18)

Added PDT status, per PDT meeting today. Once we got all r and sr, will change it into PDT+. All r ans sr, please try your best to give comments within 24 hours. If no reply, then our assumption will be within 24 hours. If you cannot do it within 24 hours, please attend the PDT meeting at 12 noon on 9/18 at the pit of bldg 21 to explain why. Many thanks. ======================= Subject: Urgent: your review and super review comments. Date: Mon, 17 Sep 2001 13:18:36 -0700 From: Tiantian Kong <tiantiankong8@netscape.com> Reply-To: tiantiankong8@netscape.com To: sspitzer@netscape.com, dveditz@netscape.com, Doug Turner <dougt@netscape.com>, law@netscape.com, alecf@netscape.com, Rajiv Dayal <rdayal@netscape.com> CC: Elaine King <elaineking@netscape.com> Hi: You got this mail because you are the r or sr of features in simple MAPI. Pathes for these has been up on the bug. On behalf on PDT, I'm requesting that you provide immediate feeback. If you cannot be back to us today, please reply by email, and cc Elaine King, as to when you'll be able to get back to us. This is an urgent request, please drop everything else that you are doing. Thx. Elaine will be calling each of you as well. Rajiv, r, Pref, 95122 Seth, sr, Pref, 95122 Dan Veditz, r log on, log off, 95117/95121 Doug Turner, sr, log on, log off, 95117/95121 Bill Law, r xpfe/bootstrap for log on, off Alec, sr, xpfe/bootstrap for log on, off Tiantian =========================

Can I get a new patch attached which includes all new files to be added (cvs diff -uN)? The patches in the bug appear to be stale.

Daily status: Completed: (1) Checked in 2 patches from 9609, and 95122 respectively. (2) Send mail and send doc is working without attachment for Excel, powerpoint. (3) Installer coding complete. 99526 (4) Get PDT approval to check in patch for 98566 tomorrow into branch. We can check in the trunk today. This patch checks if MAPI support dll is available, if available, init the dll, and expose native app support method (ensureProfile( )) from Mozilla to MAPI clients. To do: (1) Krishna: debug failure in send mail/doc from Word (2) Rajiv: fix crash in send mail/doc with attachment. (3) Sean: get r, sr for his patch for installer, and perform r for Srilatha's pref backend patch. (4) Tiantian: recruit testers from Mozilla and other organizations. (5) Srilatha: rebuild the dll, get more test app. Critical items: finding and fixing bugs for simple MAPI. Target: Check in all code into chunk by 9/21.

Status update at 3pm 9/24: (1)Focus of simple MAPI: try to get this feature work for MS Word, Excel, Powerpoint and Word Pad. (2)Plan for this week. 9/25: check in branch and trunk at the same time. 9/26: QA and bug fixing. 9/27 and 9/28: continue QA, and if basic function flow work as designed at any time, hand over to internal testers. (3)r, sr turnaround has been very speedy. Great job. Thx. Please keep it up. logon/off: sr, Doug. r, Dan. Pref backend: r, Sean and Dan. sr, mscott. Send doc: sr, Seth bug 100669: r, JF. sr, mscott. (Patch for excel will be posted soon. Continue working on Word.) (4) note: check all code in trunk on last Friday has not been possible because of unresolved issues.

This is one of the changes agreed we needed from the PDT mtg. Mark just PDT to track for now.

Status as of 5:30pm. Lowlight: check in has not been possible today since we are still waiting for r/sr stamp for 95117, sr stamp for 95122. Everyone in simple MAPI team has been talking with, IM, emailing reviewer and super reviewer. (1) Got PDT+ for 95113 (send mail) and 95116 (send doc) (2) At the request of PDT, Doug is working to fix the STL problem in 95117. Dan is half way through his r comments. (3) Srilatha implemented all changes from review, over to msott for sr. (4) Got user guide from John, our tech writer. (5) Rajiv fixed the blocker issue of 100669. Patch in review. To do. Krishna: work on Dan's r comments when available, work with Doug. Srilatha: contact msott, ensure that sr stamp is obtained before noon on 9/26. Rajiv: try to get r and sr stamp before 3:30pm on 9/26. Tiantian: review user guide. Doug: fix STL in 95117. msott: sr for 95122 before noon 9/26, sr for 100669 before 3:30pm on 9/26 Dan: deliver r of 95117 today.

Status at 5pm on 9/26. Lowlight: We were hit by a thunder called "Turbo". PDT requested that we made a private build from the 0.9.4 branch to fully test simple MAPI with/without turbo, with single/multiple profile, etc. Highligts: Got sr stamp for 95122 and 100669. Doug produced a patch to solve the STL problem, Krishna worked over midnight, implemented all comments, and produced a new patch for 95117.

can you people who are working on this let us know when (and where) a reasonably stable build is available with it included so that we users can test it?

Hi, James: Sorry for keeping you and other users waiting so long. I understand your frustration. Our engineers are working very hard to deliver this feature. Current best estimates that I have is by Monday, 10/1, to deliver a reasonably stable build that has partial simple MAPI. Further information will be provided when it becomes available. We'll try to complete a private build today, then our QA will test it on Friday. Developers will try to fix any bugs found by QA.

Correction to Tiantian's 2001-09-27 10:59 comment: The PDT requested a private BRANCH, from which any number of people (including the release team) can create test builds and examine the full source diffs, not simply a binary test build from private sources.

Critical items: (1) Delivering the private build to Trix and Esther for testing today. (2) Bug fixing. If there are a lot of bugs, may need mailnews team's help. (3) Reaching a stable status on the private branch on 10/1. In progress: (1) Developers are doing unit test on the private branch. (Rajiv, Krishna, Srilatha) (2) User guide for simple MAPI. (John, Robin, Trix, Tiantian) (3) Updating the test cases to include cases for single/multiply profile running with/without turbo mode.(Trix) (4) Alias that allow people to sign up to test simple MAPI. (Elaine, Tiantian) (5) Investigation about security issue of sMAPI. ( Tiantian )

Please note that a new component called "simple MAPI" has been opened, so that bugs for simple MAPI can be opened.

Here's a query to find all bugs about simple MAPI, including the meta bug. http://bugzilla.mozilla.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=&emailtype1=substring&emailassigned_to1=1&email2=&emailtype2=substring&emailreporter2=1&bugidtype=include&bug_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&product=MailNews&component=Simple+MAPI&short_desc=&short_desc_type=allwordssubstr&long_desc=&long_desc_type=allwordssubstr&bug_file_loc=&bug_file_loc_type=allwordssubstr&status_whiteboard=&status_whiteboard_type=allwordssubstr&keywords=&keywords_type=anywords&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&namedcmd=pdt%2B&newqueryname=&order=Reuse+same+sort+as+last+time

*** Bug 102463 has been marked as a duplicate of this bug. ***

For build and testing information, please see bug: 102570, branch landing bug

(1)We have checked in the branch landing bug to 0.9.4. (2)All in progress items from previous statues has been resolved. (3)Completed bug triage for all sMAPI bugs. In progress now: Krishna: bug 101816, 102392 Rajiv: 102798, 103313, also investigate 102821 Srilatha: 103260, 102918. Trix / Yulian / testers : test, test, test.... Tiantian: upates to user guide, etc. Dan: utility to allow administer to turn on the silent send feature. Asked Scott for help on the migrated profile bug: 102928

One more must fix that has been assigned to Dan yesterday, bug 102795

Update: Checked in patches for bug 103260, bug 102821, bug 103410, and bug 102798 In progress: bug 102392, bug 102918, bug 103313. Target date for fixing, by 10/10.

Srilatha is working on bug 103897, bug 103908, target 10/10

Bug 102392, bug 103313, bug 103897, bug 103908, has all been checked into the branch last night. GREAT JOB.

Over the last couple of days, we have fixed some bugs. Among them: bug 102389 ( which was reopened), bug 104091, bug 104275. Investigation has been done for the following bugs, and decision has been made to deal with them at the next release: bug 102645, bug 103230, bug 104237, bug 104256, bug 104258, bug 104256, bug 104291, bug 104491. In progress now: bug 103232, bug 104943.

Another bug 104938, already has patch, r, sr, PDT+. We'll check in to the branch today.

removing nsenterprise+ keyword since this is the metabug

Th three bugs from yesterday has been verified by Trix. No stop-ship bugs today.

Since all the dependency bugs are fixed and verified in the 0.9.4 branch, and has been baking in the branch successfully since 10/17, I'm marking this meta bug as fixed. Trix: add verify? The bugs which Hong added as being blocked by this meta bug are from NS4.x. Right now, support NS4.x is not the duty of our team. I'll talk to Greg about this.

marking verified