118119 - Outlook/Outlook Express functionality broken by bug 73868

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P2)

Description

[John Marmion]

The fix for bug 73868 eliminated the use of creating RDF resources for cards for
MAPI, LDAP and Outlook. The MAPI and LDAP code was modified accordingly but the
Outlook RDF resource supporting both MAPI(Outlook) and WAB(Outlook Express) was
not. 

This bug is a Windows only bug.

Comment 1

[John Marmion]

Attachment: Patch to re-enable Outlook and Outlook Express data

Outlook and Outlook Express Address Books can be accessed in Mozilla by
manually  editing the prefs.js file. The bug 83100 will allow the UI to achieve
this. The Outlook and Outlook Express Address Books appear in the left-hand
pane of Mozilla following the fix for bug 73868 but no data appears. This patch
will enable the data. The 'quick search' feature is still outstanding. 

I have also taken this opportunity to include a one line fix to
nsAbWinHelper.cpp which will enable Outlook data when it is configured in
Corporate Local mode as opposed to Internet-only mode.

Comment 2

[racham]

Sending Seth's way.

Comment 3

[John Marmion]

The quick search feature introduced by bug #83023 works for both Outlook and OE
when this patch is applied. I reported earlier that this issue was outstanding.
It works in an optimized build but I get a debug assertion failure on threading
issues in a DEBUG build. 

Comment 4

[John Marmion]

I get the following Debug Assertion failure attempting a quick search following
this patch:

nsDebug::Assertion(const char * 0x0133cf28, const char * 0x1010f450, const char
* 0x1010f41c, int 0x00000210) line 290 + 13 bytes
NS_CheckThreadSafe(void * 0x009e12b0, const char * 0x0133cf28) line 528 + 34 bytes
nsAbView::Release(nsAbView * const 0x0541f9b0) line 68 + 58 bytes
nsCOMPtr<nsIAbListener>::~nsCOMPtr<nsIAbListener>() line 491
nsCOMPtr<nsIAbListener>::Assert_NoQueryNeeded() line 503
nsCOMPtr<nsIAbListener>::nsCOMPtr<nsIAbListener>(const
already_AddRefed<nsIAbListener> & {...}) line 545
nsAddrBookSession::NotifyDirectoryItemAdded(nsAddrBookSession * const
0x049fd030, nsIAbDirectory * 0x0541f218, nsISupports * 0x05420ce0) line 121
nsAbOutlookDirectory::OnSearchFoundCard(nsIAbCard * 0x05420ce0) line 1031
nsAbDirSearchListener::OnQueryItem(nsAbDirSearchListener * const 0x053f8e20,
nsIAbDirectoryQueryResult * 0x05420a50) line 106 + 26 bytes
nsAbOutlookDirectory::ExecuteQuery(nsIAbDirectoryQueryArguments * 0x053f7fd0,
nsIAbDirectoryQueryResultListener * 0x053f8e20, int 0xffffffff, int 0x00000000,
int 0x00000001) line 1080
QueryThreadFunc(void * 0x053f8cb0) line 918
_PR_NativeRunThread(void * 0x053fbd70) line 413 + 13 bytes
_threadstartex(void * 0x053fbcd0) line 212 + 13 bytes
KERNEL32! 77f04ede()

Outlook is the only Address Book that receives this. MAB or LDAP are ok. I can't
see what Outlook is doing is incorrect.

Comment 5

[John Marmion]

Attachment: Keep patch up-to-date and solely focussed on bug

I am still having a problem with assertions due to threading issues with this
patch. The fact that Outlook is an asynchronous search and the Query is
executed in a separate thread combined with the new implementation of
nsAbView() is causing some difficulty. I still have not resolved this.

Comment 6

[scottputterman]

reassigning to John since he has the fix.

Comment 7

[Vidar Haarr (not reading bugmail)]

we need reviews here :)

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

If there are still threading assertions, the patch is not yet ready for review.

Comment 9

[John Marmion]

Looks like we have resolved this threading assertion failure which mainifests
itself because the current thread is not the UI thread. Much appreciation to
Cyrille Moureaux for pointing out how to resolve this by using the
NS_GetProxyForObject() and use a proxyListener when running the OutLook Query. I
will update and post a patch and chase a review for this today. 

Comment 10

[John Marmion]

Attachment: Update Patch with UI Threading Assertion failure fix

Latest patch. Will request a review for this today.

Comment 11

[Peter Van der Beken [:peterv]]

Comment on attachment 96003 [details] [diff] [review]
Update Patch with UI Threading Assertion failure fix

>+    retCode = NS_GetProxyForObject(NS_UI_THREAD_EVENTQ,
>+                     NS_GET_IID(nsIAbDirectoryQueryResultListener),
>+                     NS_STATIC_CAST(nsIAbDirectoryQueryResultListener *, new nsAbDirSearchListener(this)),
>+                     PROXY_SYNC | PROXY_ALWAYS,
>+                     getter_AddRefs(proxyListener));
>     
>-    queryListener = new nsAbDirSearchListener(this) ;
>-    return DoQuery(arguments, queryListener, -1, 0, &mSearchContext) ;
>+    NS_ENSURE_SUCCESS(retCode, retCode) ;
>+    return DoQuery(arguments, proxyListener, -1, 0, &mSearchContext) ;
> }

Please move the NS_ENSURE_SUCCESS(retCode, retCode) ; one line up.

r=peterv.

Comment 12

[John Marmion]

Attachment: Update patch as requested by the reviewer

Thanks for your time Peter.

Comment 13

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

Comment on attachment 99351 [details] [diff] [review]
Update patch as requested by the reviewer

sr=sspitzer, r=peterv

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You checked in while the tree was closed!

Comment 15

[John Marmion]

my apologies. I am a rookie at checking in. I checked that the tinderbox was not
red but was not aware that the tree was closed. It won't happen again.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Don't worry, I've made that mistake before myself. Just thought I'd let you know
:-).

Comment 17

[John Marmion]

This fix is now checked in. Thanks to everyone who contributed to this. I have
verified that this fix works by running the Windows nightly build 1.2a 20020917.
To enable this feature you need to manually editing the preferences file [see
http://abzilla.mozdev.org#Outlook

Comment 18

[Stuart Summerville]

Is Abzilla/Outlook still working in latest builds? I've followed the
instructions at abzilla.mozdev.org & can't get it to work.

I presume from this bug, that all that is required is to add the 4 entries to
prefs.js, right?

- If I add the 4 entries as described at abzilla.mozdev.org, I see no mapitest
entry in the AddressBook, although the prefs.js does get the two new entries
added, as suggested at a.m.o. It also seems to remove the ".position" entry, to
my surprise.

- If I delete the uri entry (don't ask how I discovered this) from prefs.js, I
then see the mapitest address book listed, but it contains no records.

Moz = 2002121408
Sys = Win2K SP3
OL  = from OfficeXP (10.4608.4219) SP-2

Am I asking too much with OfficeXP & Win2k?

sTu.

Comment 19

[John Marmion]

Stuart, this should be working. And yes, you are correct, all that should be
needed is to manually add 4 entries to the prefs.js file. Can you attach your
pref.js file to this bug? Or at the very least paste the 4 lines you added here.
Thanks.

Comment 20

[Stuart Summerville]

Firstly, the entries I add:

user_pref("ldap_2.servers.mapitest.description", "mapitest");
user_pref("ldap_2.servers.mapitest.dirType", 3);
user_pref("ldap_2.servers.mapitest.position", 1);
user_pref("ldap_2.servers.mapitest.uri", "moz-aboutlookdirectory://op/");

Then the resulting entries after I load MOZ to find mapitest missing, and then 
quit MOZ:

user_pref("ldap_2.servers.mapitest.description", "mapitest");
user_pref("ldap_2.servers.mapitest.dirType", 3);
user_pref("ldap_2.servers.mapitest.filename", "mapitest.mab");
user_pref("ldap_2.servers.mapitest.replication.lastChangeNumber", 0);
user_pref("ldap_2.servers.mapitest.uri", "moz-aboutlookdirectory://op/");


The same happens if I try other values of mapitest.position. If I remove the 
mapitest entries, and then do an import of my OL contacts, they work fine with 
the corresponding ldap_2.servers.contacts.position being set to 3 (no 
other .position entries exist), so I'd try mapitest (without the contacts entry 
there) at values of 3 or 4 with the same result.

This all came about since I wanted to relocate my everyday .mab file to 
somewhere nicer than the default. Apparently this isn't (yet) possible, so I 
discovered abzilla.

I don't suppose the fact that this bug is flagged as NT only has anything to do 
with this...?

sTu.

Comment 21

[John Marmion]

sTu, the positions '1' and '2' are reserved for the "Personal Address Book" and
"Collected Addresses". Thus '3' is the next available position if there are no
other new Address Books. Anyway, I quickly tested this against 1.3a and it does 
work. I simply created a new Address Book called Friends. I then edited the
prefs.js, copied all the Friends entries, changed Friends to Outlook, modified
the dirType to 3, incremented the position and added the uri entry. It worked
fine. I do know that if it fails to connect to Outlook, then the OP Contacts
will not appear as a valid Address Book in the left pane. 

One simple test to see if mozilla attempts to access Outlook is to configure
Mozilla as the default Internet email client. When you then run mozilla and
activate the Address Book, you should see the MAPI Windows Message "Either there
is default mail client or the current client mail client cannot fulfill
.............". i.e. MS Outlook must be set as the default email client.