Outlook/Outlook Express functionality broken by bug 73868

RESOLVED FIXED in mozilla1.0

Status

SeaMonkey
MailNews: Address Book & Contacts
P2
normal
RESOLVED FIXED
16 years ago
13 years ago

People

(Reporter: John Marmion, Assigned: John Marmion)

Tracking

(Blocks: 2 bugs)

Trunk
mozilla1.0
x86
Windows NT
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Assignee)

Description

16 years ago
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.
(Assignee)

Comment 1

16 years ago
Created attachment 63490 [details] [diff] [review]
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

16 years ago
Sending Seth's way.
Assignee: racham → sspitzer
(Assignee)

Comment 3

16 years ago
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. 
(Assignee)

Updated

16 years ago
Blocks: 83100
(Assignee)

Comment 4

16 years ago
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.
(Assignee)

Updated

16 years ago
Blocks: 101533
(Assignee)

Updated

16 years ago
Blocks: 101553
No longer blocks: 101533
(Assignee)

Updated

16 years ago
Blocks: 118744
(Assignee)

Comment 5

16 years ago
Created attachment 69489 [details] [diff] [review]
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.
Attachment #63490 - Attachment is obsolete: true
(Assignee)

Updated

16 years ago
Blocks: 111968
(Assignee)

Updated

16 years ago
Priority: -- → P2
Target Milestone: --- → mozilla1.0
(Assignee)

Updated

16 years ago
Blocks: 127848
(Assignee)

Updated

16 years ago
Blocks: 127879

Comment 6

15 years ago
reassigning to John since he has the fix.
Assignee: sspitzer → john.marmion
(Assignee)

Updated

15 years ago
Blocks: 135689
we need reviews here :)
Keywords: patch, review

Comment 8

15 years ago
If there are still threading assertions, the patch is not yet ready for review.
Keywords: patch, review
(Assignee)

Comment 9

15 years ago
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. 
Status: NEW → ASSIGNED
(Assignee)

Comment 10

15 years ago
Created attachment 96003 [details] [diff] [review]
Update Patch with UI Threading Assertion failure fix

Latest patch. Will request a review for this today.
Attachment #69489 - Attachment is obsolete: true
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.
Attachment #96003 - Flags: review+
(Assignee)

Comment 12

15 years ago
Created attachment 99351 [details] [diff] [review]
Update patch as requested by the reviewer

Thanks for your time Peter.
(Assignee)

Updated

15 years ago
Attachment #96003 - Attachment is obsolete: true
Comment on attachment 99351 [details] [diff] [review]
Update patch as requested by the reviewer

sr=sspitzer, r=peterv
Attachment #99351 - Flags: superreview+
Attachment #99351 - Flags: review+
You checked in while the tree was closed!
(Assignee)

Comment 15

15 years ago
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.
Don't worry, I've made that mistake before myself. Just thought I'd let you know
:-).
(Assignee)

Comment 17

15 years ago
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
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 18

15 years ago
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.
(Assignee)

Comment 19

15 years ago
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

15 years ago
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.
(Assignee)

Comment 21

15 years ago
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.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.