Created attachment 1875257 [details]
The video of the situation.
Description of problem:
When users want to edit an existing contact (add a record to it), the action creates a new (empty) contact with the same name, so it looks like there are suddenly two same contacts in the contact list, one is empty and the other is the original (now updated) contact.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. See the attached video.
An updated contant gets doubled.
The contact should be updated with no issues.
Proposed as a Blocker for 36-final by Fedora user lruzicka using the blocker tracking app because:
I am proposing this as a blocker because it might violate the Basic functionality criteria.
I can confirm this problem. However, it seems to happen only if you change the email, changing other fields doesn't trigger it. Also, after you restart the application, the duplicate contact is gone, and there's only one contact with the correct (updated) email.
Created attachment 1875308 [details]
contacts with same email
The email handling is even more confusing. A probably-related issue: Instead of editing the email, if you instead create a new contact with the same email (intentionally or by accident), then you'll see the contact *description* (and not just name) duplicated. Each section is there twice, once normally and once under "Local Contact". The displayed name randomly switches between the first and the second contact name. If you delete the contact, one of two things randomly happen: a) both contacts are deleted b) only one contact is deleted, and the second one appears after a while in your address book with its original details.
I can split this into a separate bug if you want. But it might be caused by the same problem - broken email handling.
I see what you mean. I'm inclined to say create a separate bug for this. It may be the same problem or it may not. In any case, I voted -1 for blocking on this based on comment 0, but I'm leaning toward +1 for a comment 3 bug. So at least for the purposes of the blocker process, it's probably better to split them.
Hi, Contacts maintainer here (who didn't follow fedora BZs about it until now):
When you start up gnome-contacts, does it give you a warning (sometimes after a few seconds) from libfolks about some E-D-S store not being found?
After that, can you go to the "Change Addressbook" dialog and see if any addressbook is checked?
If any item is selected, I would suspect it's because the "local address book" is checked. Can you confirm?
(In reply to Niels De Graef from comment #5)
> When you start up gnome-contacts, does it give you a warning (sometimes
> after a few seconds) from libfolks about some E-D-S store not being found?
I don't see any message in journal from gnome-contacts of libfolks, if I just start the app and wait.
> After that, can you go to the "Change Addressbook" dialog and see if any
> addressbook is checked?
Local Address Book is checked (no other is available). 
> If any item is selected, I would suspect it's because the "local address
> book" is checked. Can you confirm?
 Please note that there's a little bug when starting gnome-contacts for the first time. It allows you to select address book, and local address book seems to be checked, but you can't continue, until you click on it at least once. I believe the item is not really checked, it just looks checked. The issue is even more visible if you add an online account before hand - if you click on the online address book in the initial dialog, you can see both items checked, local and online. But I don't think this affects anything, I think it's just a UI-related glitch.
In today's Go/No-Go meeting, we agreed to reject this as a blocker and accept it as a freeze exception. This falls outside of "basic functionality", but is worth fixing if possible
This is normally fixed in the latest main branch upstream.
Well, it doesn't fail exactly this way any more, but it still doesn't work right: https://bugzilla.redhat.com/show_bug.cgi?id=2130657
Note, this bug is filed against F36, so it can't be closed just because upstream behaviour changed in 43. There'd need to be a 42.1 release or the change would need to be backported downstream to close this bug.
(In reply to Adam Williamson from comment #9)
> Well, it doesn't fail exactly this way any more, but it still doesn't work
> right: https://bugzilla.redhat.com/show_bug.cgi?id=2130657
Looking into it.
> Note, this bug is filed against F36, so it can't be closed just because
> upstream behaviour changed in 43. There'd need to be a 42.1 release or the
> change would need to be backported downstream to close this bug.
Just wanted to note that backporting that whole rewrite would basically mean the same as backporting the whole of 43, so from an upstream perspective that's not going to happen. (Fedora is free to backport what it wants though)
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version'
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora Linux 36 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.
Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.
If you are unable to reopen this bug, please file a new report against an
Thank you for reporting this bug and we are sorry it could not be fixed.