Open Bug 829629 Opened 12 years ago Updated 1 year ago

transferring a contact to another address book overwrites existing contacts in that address book

Categories

(Thunderbird :: Address Book, defect)

x86_64
Windows 7
defect

Tracking

(Not tracked)

People

(Reporter: munk, Unassigned)

Details

(Whiteboard: [dupeme?])

Attachments

(2 files)

if I click on the star besides a listed contact(i.e. in a single sent email in the sent folder) I am offered to work on the contact and transfer it to another existing address book. In this process this contact overwrites an existing contact in the address book where it's transferred to, confusing all information: i. e. name and email is overwritten, while all other Information (display name, telefone and addresses) of the old contact remain. Result is a complete chaos...
I tried this, and wound up with two address book entries in the folder I "transferred" the contact to. 1. in msg display create contact in contact AB1 2. in address book copy contact to AB2, and alter the display name 3. in msg display click contact and change contact to AB1 results: two address book entries
Whiteboard: [dupeme?]
I can confirm this behaviour on Thunderbird 45.4.0 / Windows 10 x64. My setup: Sogo Connector 31.0.3 setup with a CardDAV account on posteo.de. (The bug also appears with internet turned off though, so no synchronization happening.) Steps to reproduce: 1. In the email view, click on an recipient saved in any address book. 2. Choose "Edit contact". 3. Choose the address book connected via Sogo Connector (AB2) (Posteo.de in my case - it should be one with contacts that have stored phone numbers, I think). 4. Search for the contact in the AB2. It shows up with a random phone number and possibly other fields mixed up. I found that all confounded contacts had phone numbers starting with "+" (international prefix, might be +43 or +36, etc...) though that might be coincidence. I think this is a major bug, which makes Thunderbird extremely unreliable for saving contacts in that shared address book. If you need more information, just ping me. PS.: This might be connected to this bug in the Sogo bug tracker: https://sogo.nu/bugs/view.php?id=3828 which has been filed only yesterday.
I can confirm the behaviour in Thunderbird 52.3.0 (Windows 10 x64): Moving a contact to another address book via the favorite icon "Edit contact" menu in the message pane corrupts another contact in the target address book. This is a critical bug! Who can set the status to "Confirmed"?
Experienced the same bug on Arch Linux, Thunderbird 60.3.3. Could reproduce the problem on Linux Mint, Thunderbird 60.2.1. Let A be the contact which is edited and B be the contact which is overwritten. I'm unsure how B is selected. It seems like B is neither the first/last one nor the oldest/newest. A is never moved (as I would expect), but always copied over B. All fields (Name, Address, Phone, ...) of A overwrite the corresponding fields of B. If B has some fields that A does not have then these fields of B remain unchanged. Without these remaining fields I would probably never found out about this silent data corruption. I'm a shocked that this bug report is 6 years old, because the bug seems quite critical.
Attached file Steps to reproduce
Steps to reproduce corruption of a random contact when "moving" a contact from one address book to another using the star menu displayed in e-mail headers.
Status: UNCONFIRMED → NEW
Ever confirmed: true

I can reproduce this exactly as in schaetzc's screenshots, except my second address book is an address book created by tbsync with "Provider for CalDAV and CardDAV".

I'm using Thunderbird 68.10.0

Interestingly I have two machines (one desktop and one laptop) with the same OS (Linux Mint 20), same software, same Thunderbird configuration and the bug only happens on my laptop.

It's been happening for at least a year. At first I thought I messed something up during the configuration, but I've erased my entire Thunderbird profile and recreated it on the bad machine - this bug is still 100% reproducible. I did that again today, same results.

As a workaround I have to remember not to move contacts to my synced address book via the "Edit Contact" popup. If I move them in the Address Book window - the overwriting/merging doesn't happen.

It does really suck that this bug is 8 years old, and seems to happen on different operating systems with different addons installed. It's got to be a problem with Thunderbird's "Edit Contact" popup window, or whatever underlying interface that uses. But I guess there aren't enough of us using it for anyone to investigate.

I'm a software developer (I worked on Mozilla too many years ago) and I'm willing to help with tracking down the problem if someone can guide me. I can't do it on my own.

Flags: needinfo?(geoff)

On the machine where you observe this behavior with a TbSync address book, can you also reproduce the issue with just using local address books?

Not right away. I added an address book "test" and one contact in there, then followed the steps to copy 3 more contacts into there. They all got copied fine.

Other than that it's not a Tbsync address book - the only obvious difference is that the TBSync one has 161 contacts.

Then I copied all 161 contacts from the TBSync address book to "test" and followed the steps again. The bug was reproduced on the first shot.

So it appears that it's probably not a TBSync problem.

Severity: normal → S4
Flags: needinfo?(geoff)

Since the new address book was released, I tested my steps to reproduce again.

The star icon next to correspondents in email is no longer shown. Now we have to click on the correspondent (which brings up a menu) and then click "Edit Contact" (which brings up the same or at least equivalent popup as the star button did before), see screenshot.

I can no longer reproduce the bug.
The contact is moved correctly to the selected address book.
The other contacts in the target address book remain intact.
I tested on 102.15.1 (32-bit) on Windows 10.

Seems like the rewrite of the address book "fixed" the bug (that is, the rewrite did not have that bug in the first place).
This ticket can be closed.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: