Bug 2079274 - Contact deletion is unreliable
Summary: Contact deletion is unreliable
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-contacts
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException RejectedBlocker
Depends On:
Blocks: F36FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2022-04-27 10:17 UTC by Kamil Páral
Modified: 2023-03-06 19:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-03-06 19:45:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
bug demonstration video (2.12 MB, video/webm)
2022-04-27 10:17 UTC, Kamil Páral
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME gnome-contacts issues 241 0 None opened Contact deletion is unreliable 2022-04-29 18:35:34 UTC

Description Kamil Páral 2022-04-27 10:17:22 UTC
Created attachment 1875320 [details]
bug demonstration video

Description of problem:
Deleting contacts seems broken. If you delete a contact and close the app, it will most probably not get deleted. You have to wait until the notification disappears and then close the app, to make it work. If you delete multiple contacts, there are some timing issues which will seemingly randomly not delete some contact even though others were deleted. See the video.

Version-Release number of selected component (if applicable):
gnome-contacts-42.0-1.fc36.x86_64

How reproducible:
always

Steps to Reproduce:
1. delete a contact and close the app
2. open the app and see the contact still there

(not sure how to reproduce the multi-contact deletion problems)

Comment 1 Kamil Páral 2022-04-27 10:18:10 UTC
Proposing as a Final blocker due to the basic functionality criterion:
https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality

Comment 2 lnie 2022-04-27 12:12:32 UTC
I think it's a supposed behavior,as the notification says:it's deleting(which means it's not done).
Checked on the f35 system, you will see the same symptom,but the notification claims it's deleted,
that is a bug.
That being said,I'm wondering why deleting a contact information will take such a long time.

Comment 3 Kamil Páral 2022-04-27 12:54:25 UTC
> I think it's a supposed behavior

I don't believe so. It is a common practice to give you an Undo button for a limited time, but the operation is considered done if you do anything else (like another operation or closing the app).

Comment 4 lnie 2022-04-28 08:23:50 UTC
> It is a common practice to give you an Undo button for a limited time,but the operation is considered done if you do anything else (like another operation or closing the app).

Yes, you are right,but the warning message would be "deleted" instead of "deleting",and yes,the app should delete the info unless users click"Undo".
But I guess what is happening here is that the developer has already known this issue,it's just can't be fixed easily and this is a very late bug.
I'm -1 blocker on this one unless there is an easy fix:)

Comment 5 Niels De Graef 2022-04-28 13:04:16 UTC
(In reply to lnie from comment #4)
> > It is a common practice to give you an Undo button for a limited time,but the operation is considered done if you do anything else (like another operation or closing the app).
> 
> Yes, you are right,but the warning message would be "deleted" instead of
> "deleting",and yes,the app should delete the info unless users click"Undo".
> But I guess what is happening here is that the developer has already known
> this issue,it's just can't be fixed easily and this is a very late bug.

More like: the developer didn't know because there wasn't any upstream bug about it ;)

Comment 6 Ben Cotton 2022-04-28 19:21:47 UTC
In today's Go/No-Go meeting, we agreed to delay a decision on blocker status but grant a freeze exception. We are gridlocked on whether the severity of this bug merits blocker status, but there's unanimous support for fixing it if possible
https://meetbot.fedoraproject.org/fedora-meeting/2022-04-28/f36-final-go_no_go-meeting.2022-04-28-17.01.log.html#l-529

Comment 7 lnie 2022-04-29 03:49:12 UTC
(In reply to Niels De Graef from comment #5)
> (In reply to lnie from comment #4)
> > > It is a common practice to give you an Undo button for a limited time,but the operation is considered done if you do anything else (like another operation or closing the app).
> > 
> > Yes, you are right,but the warning message would be "deleted" instead of
> > "deleting",and yes,the app should delete the info unless users click"Undo".
> > But I guess what is happening here is that the developer has already known
> > this issue,it's just can't be fixed easily and this is a very late bug.
> 
> More like: the developer didn't know because there wasn't any upstream bug
> about it ;)

hmm,then why the warning message is changed from "Deleted"(which is the standard word) to "Deleting"? 
Anyway,I report it to upstream ,just in case:
https://gitlab.gnome.org/GNOME/gnome-contacts/-/issues/241

Comment 8 Geoffrey Marr 2022-05-02 18:29:08 UTC
Discussed during the 2022-05-02 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" was made as deletion does work after a delay, and the notification's grammar does technically convey this, therefore we have decided that this doesn't quite meet the bar of a "basic functionality" failure.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-05-02/f36-blocker-review.2022-05-02-16.00.txt

Comment 9 Niels De Graef 2023-03-02 10:25:28 UTC
I guess this one can be closed given the upstream status? :)

Comment 10 Kamil Páral 2023-03-06 19:45:16 UTC
Sure. I'll try to soon retest this for F38, but for the moment we can definitely mark this as closed.


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