192994 - Rename category, add a card in corresponding Moz AB (card deleted)

Status: VERIFIED FIXED

(MailNews Core Graveyard :: Palm Sync, defect)

Description

[Ninoschka Baca]

Trunk build 2003-02-12: WinXP

Overview: Renaming a category on the palm while adding a card to the
corresponding AB in Mozilla AB results in the card being deleted.

Steps to reproduce:

1. Start with a category/mozilla address book with the same name which have no
records/cards (i.e. AB1)
3. On the palm device rename the category (i.e. AB1 --> AB2)
4. In the mozilla address book add one card (i.e. card1)
5. Perform a Hotsync

Actual Results: The renamed category/mozilla address book appear on both (AB2)
but the newly added card is gone.

Expected Results: The card added in step# 4 should appear in the renamed
category/mozilla address book on both sides. (i.e. AB2/card1)

Note: This bug was written as a result of bug# 189123.

Comment 1

[Ninoschka Baca]

Marking nsbeta1.

Comment 2

[Ninoschka Baca]

If the new card is on the palm device side then it works as expected:

1. Start with a category/mozilla address book with the same name which have no
records/cards (i.e. AB1)
3. On the palm device, rename the category (i.e. AB1 --> AB2)
4. On the palm device, add one card to the newly renamed category(i.e. AB2/card1)
5. Perform a Hotsync

Actual Results: The palm device and the Mozilla AB both have the newly created
category/mozilla address book and each has a copy of the new card (i.e.
AB2/card1) as Expected.

Comment 3

[Samir Gehani]

Mail triage team: nsbeta1+/adt2

Comment 4

[Cavin Song]

It is caused by the fact that category id for the renamed category was
re-numbered. Because Plam category ids are the keys to tie addrbooks on both
sides together, when this happens the code will treat the renamed category as a
NEW category and will create a new addrbook in mozilla (since this category id
is new to mozilla) and will remove the corresponding addrbook from mozilla
(since it's not seen on Palm, ie removed). 

I don't know when this will happen and under what circumstances when a category
is renamed on palm but it does happen sometimes but not all the time. When the
category ids are kept intact after rename this problem does not happen.

Comment 5

[Cavin Song]

As an experiment, I put more debug info in the conduit log and I found that
category indexes were never changed even when category ids were changed. So it
looks like we should be storing category indexes as the key in our database
instead of the category ids.

Comment 6

[Cavin Song]

Attachment: Proposed patch, v1

The main fix for this bug is to use the Palm category index, instead of
category id, as the key to link/tie moz addrbooks and Palm categories together.
The patch does look big but a lot of them are only variable name changes (from
categoryId to categoryIndex). Other changes include:

1. Memory deallocation warning from MS COM in nsAbIPCCard.cpp().
2. Pass additional parameter ‘category id’ to nsSynchronizeAB(). This is the
only MSCOM API that needs both category index and category id.
3. Modify some log info to make debugging easier.
4. Change some of the MS COM interface methods to use LONG, instead of DWORD
which is unsigned long, for category index and id which can be -1.
5. Incorporate patch from bug 197494 (add code to not delete un-synced moz
addrbooks and add more log info to track Palm category creation).

Comment 7

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

Comment on attachment 117918 [details] [diff] [review]
Proposed patch, v1

r/sr=sspitzer

Comment 8

[Cavin Song]

Fix checked in.

Reminder: since the key field has changed (to category index) you can't use the
existing 'synced' addrbooks to do any more sync with the new code. So you should:

1. Sync your palm categories with mozilla addrbooks using the build without this
fix (ie, make sure your palm has the up-to-date info).

2. Run a build with this fix in it, create a new profile and then sync your palm
categories with the addrbooks in the new profile.

Comment 9

[Cavin Song]

The patch fails for the following scenario:

 Add a new card in the moz addrbook and then sync, the card is not added to palm.

I think it may be caused by removing of the following line in nsAbIPCCard.cpp:

-    memset(card, 0, sizeof(nsABCOMCardStruct));

The net effect is that the dll on the moz side returns error code of S_OK (ie,
0) but the moz conduit gets a different value (ie, -2147023898).

Comment 10

[Cavin Song]

Attachment: Fix for cards not getting synced to palm

Putting back memset() call seems to fix the problem.

Comment 11

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

Comment on attachment 118474 [details] [diff] [review]
Fix for cards not getting synced to palm

sr=sspitzer

Comment 12

[Cavin Song]

Fix checked in.

Comment 13

[Ninoschka Baca]

Trunk build 2003-03-26-11: WinXP
Verified Fixed.

- The original scenario is now working. Rename category on palm device, add a
card to corresponding address book, hotsync and the address book now has the new
name and retains the new card. The new card also appears on the palm device.

- Adding cards and address book on the palm still appears in the Mozilla AB
after a hotsync just as before.