Bug 2072462 - Saved entries can't be deleted in GNOME Connections
Summary: Saved entries can't be deleted in GNOME Connections
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-connections
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Felipe Borges
QA Contact:
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F36FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2022-04-06 11:15 UTC by Kamil Páral
Modified: 2022-04-13 09:56 UTC (History)
5 users (show)

Fixed In Version: gnome-connections-42.1.1-1.fc36 gnome-connections-42.1.2-1.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-04-13 09:04:50 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Gitlab GNOME connections issues 84 0 None None None 2022-04-06 11:16:39 UTC

Description Kamil Páral 2022-04-06 11:15:41 UTC
Description of problem:
When you have some saved connection entries in gnome-connections and want to remove them, in most cases they seem to get removed, but then re-appear when the application is restarted. That means the app gets cluttered with lots of IP addresses that you used in the past and you can't get rid of them, which makes the navigation pretty bad.

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

How reproducible:
always

Steps to Reproduce:
1. start gnome-connections
2. create some new connection entries. They don't need to be real, connecting to an invalid IP/hostname will still create an entry. So e.g. try to connect over VNC to "foo", "bar" a "baz", that will fail to connect, but will create 3 entries for you.
3. remove foo, bar and baz entries
4. wait until the info bar "connection has been deleted" disappears (this is important)
5. close and reopen gnome-connections
6. see foo, bar and baz entries back


Actual results:
entries are not deleted, they return after app restart

Expected results:
entries are deleted

Additional info:
There are workarounds to force the app the actually delete the entries:
1. One workaround is to click the X button on the "connection has been deleted" info bar. That will delete the entry. If you're deleting multiple entries, you need to click the X button for each of them, i.e. you can't delete multiple entries and then click the X button only on the last notification bar.
2. A second workaround is to close the whole app before the "connection has been deleted" info bar disappears. That will also delete the entry. This makes deleting multiple entries quite impractical, though.

An upstream report:
https://gitlab.gnome.org/GNOME/connections/-/issues/84

Comment 1 Kamil Páral 2022-04-06 11:16:40 UTC
Proposing for a blocker consideration. Do you deleting existing entries a basic functionality of a remote desktop viewer?

https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality

Comment 2 Felipe Borges 2022-04-06 11:25:26 UTC
I just posted a fix for this upstream at https://gitlab.gnome.org/GNOME/connections/-/commit/f5f3baf8ee736f6b4c28fd1f4e229ef29381eab5

Comment 3 Fedora Update System 2022-04-07 13:27:23 UTC
FEDORA-2022-4f7e9dc2fb has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-4f7e9dc2fb

Comment 4 Kamil Páral 2022-04-07 17:33:50 UTC
(In reply to Fedora Update System from comment #3)
> FEDORA-2022-4f7e9dc2fb has been submitted as an update to Fedora 36.
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-4f7e9dc2fb

This bug is partially fixed now. Removing a single entry seems to work now in all cases. However, when removing multiple entries, it seems that only the last one gets removed, the others return back after app restart. The workaround seems to be wait after each deletion until the notification bar disappears, and only then remove the next entry.

Comment 5 Fedora Update System 2022-04-07 18:01:59 UTC
FEDORA-2022-4f7e9dc2fb has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-4f7e9dc2fb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-4f7e9dc2fb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 6 Fedora Update System 2022-04-11 03:33:33 UTC
FEDORA-2022-4f7e9dc2fb has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Kamil Páral 2022-04-11 08:37:03 UTC
Reopening because of comment 4.

Comment 8 Kamil Páral 2022-04-11 09:10:31 UTC
Based on votes in https://pagure.io/fedora-qa/blocker-review/issue/721 , rejected as a blocker and accepted as a freeze exception (if another fix is available before the Final release).

Comment 9 Fedora Update System 2022-04-13 09:04:21 UTC
FEDORA-2022-13ed0f323e has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-13ed0f323e

Comment 10 Fedora Update System 2022-04-13 09:04:50 UTC
FEDORA-2022-13ed0f323e has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


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