Bug 2079274
| Summary: | Contact deletion is unreliable | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||
| Component: | gnome-contacts | Assignee: | Kalev Lember <klember> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 36 | CC: | bcotton, fedoraparked, gmarr, gnome-sig, klember, lnie, ndegraef, robatino | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | AcceptedFreezeException RejectedBlocker | ||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2023-03-06 19:45:16 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1953786 | ||||||
| Attachments: |
|
||||||
Proposing as a Final blocker due to the basic functionality criterion: https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality 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. > 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).
> 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:)
(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 ;) 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 (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 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 I guess this one can be closed given the upstream status? :) Sure. I'll try to soon retest this for F38, but for the moment we can definitely mark this as closed. |
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)