Created attachment 153889 [details]
demonstration of the bug

This gets so bad, that I just have to hide the "Devices" section in Dolphin completely.

Question: is it possible that this is a Dolphin bug?

You can remove the entries created by kde-connect by right-clicking on them and choosing 'Remove'.

Patrick Silva, I'm sorry, there might be some kind of misunderstanding. I should have made it more clear. Depending on how long the user have been using KDE Connect, it may have caused hundreds and hundreds of erroneous devices to appear in Dolphin.

Please watch the video I have attached to this bug report. Manually fixing this problem one entry at a time is out of the question.

I have created two new tickets with more details:

1. https://bugs.kde.org/show_bug.cgi?id=466416
2. https://bugs.kde.org/show_bug.cgi?id=466420

Does this happen even without unpairing/repairing the device? We shouldn't create more than one entry for the same device, and I can't reproduce this.

Hello, Albert. Thank you for looking into this issue.

> Does this happen even without unpairing/repairing the device? We shouldn't create more than one entry for the same device, and I can't reproduce this.

I've re-run my tests and below are my steps to reproduce as of 2023-09-13. I don't think "unpairing/repairing" is needed to reproduce this. In fact, KDE Connect application on the desktop is not involved in my steps to reproduce at all.

Please also see the video attachment https://bugsfiles.kde.org/attachment.cgi?id=156717 in https://bugs.kde.org/show_bug.cgi?id=466416. Nobody is doing this amount of pairing/unpairing in casual use of KDE Connect.

== Prerequisites ==

1. The phone is Pixel 6a, the workaround "Use device MAC" is enabled in the settings of the WiFi network in question, as per https://bugs.kde.org/show_bug.cgi?id=466416#c7
2. The duplicates are cleared from Dolphin as per https://bugs.kde.org/show_bug.cgi?id=466420#c3
3. KDE Plasma version is 5.27.7

== Steps ==

1. Open Dolphin, ensure panel "Places" is shown, ensure checkbox "Show All Entries" is enabled (context menu of "Places").
2. Disconnect the phone from the WiFi network, force close KDE Connect on the phone
3. Connect the phone to the WiFi network, open KDE Connect on the phone
4. Observe the panel in Dolphin
5. Disconnect the phone from the WiFi network, force close KDE Connect on the phone (repeat of step 2)
6. Connect the phone to the WiFi network, open KDE Connect on the phone (repeat of step 3)
7. Observe the panel in Dolphin

== Actual result ==
- At step 4 entry "Pixel 6A" appears in the "Places" panel, as expected.
- At step 7 a second, erroneous, entry "Pixel 6A" appears in the "Places" panel.

== Expected result ==
- At step 4 entry "Pixel 6A" appears in the "Places" panel.
- At step 7 nothing new appears in the "Places" panel.

I still can't reproduce it with your steps. When the phone stops being available from the computer, the entry disappears for me. Are you on KDE Connect 23.08? If not, can you try there? Maybe it has been fixed already (although I don't remember any change regarding this...). If it continues to happen to you, there might be some difference in our steps or steps...

I am using KDE Connect 23.08:

    $ apt show kdeconnect 2>/dev/null | head -2
    Package: kdeconnect
    Version: 23.08.0-0xneon+22.04+jammy+release+build32

Before adding an item to the menu, we check if any items for the same device ID exists and we remove them, so I don't see how this could happen.

For reference, here's the code in 23.08 and in master (it has changed a bit but the logic is the same):

https://invent.kde.org/network/kdeconnect-kde/-/blame/release/23.08/plugins/sftp/sftpplugin.cpp#L63
https://invent.kde.org/network/kdeconnect-kde/-/blame/master/plugins/sftp/sftpplugin.cpp#L48

Here's how the kdeconnect:// URLs look like in my `~/.local/share/user-places.xbel`:

```
 <bookmark href="kdeconnect://d50f6d891d877492/">
  <title>Pixel 6A</title>
  <info>
   <metadata owner="http://freedesktop.org">
    <bookmark:icon name="kdeconnect"/>
   </metadata>
   <metadata owner="http://www.kde.org">
    <ID>1694595218/8</ID>
   </metadata>
  </info>
 </bookmark>
 <bookmark href="kdeconnect://d50f6d891d877492/">
  <title>Pixel 6A</title>
  <info>
   <metadata owner="http://freedesktop.org">
    <bookmark:icon name="kdeconnect"/>
   </metadata>
   <metadata owner="http://www.kde.org">
    <ID>1694595239/9</ID>
   </metadata>
  </info>
 </bookmark>
 <bookmark href="kdeconnect://d50f6d891d877492/">
  <title>Pixel 6A</title>
  <info>
   <metadata owner="http://freedesktop.org">
    <bookmark:icon name="kdeconnect"/>
   </metadata>
   <metadata owner="http://www.kde.org">
    <ID>1694631780/10</ID>
   </metadata>
  </info>
 </bookmark>
 <bookmark href="kdeconnect://d50f6d891d877492/">
  <title>Pixel 6A</title>
  <info>
   <metadata owner="http://freedesktop.org">
    <bookmark:icon name="kdeconnect"/>
   </metadata>
   <metadata owner="http://www.kde.org">
    <ID>1694677298/11</ID>
   </metadata>
  </info>
 </bookmark>
```

The different contents in tag <ID> stick out, but the `deviceId` (https://invent.kde.org/network/kdeconnect-kde/-/blame/master/plugins/sftp/sftpplugin.cpp#L43) is the same for every URL.

I don't know a lot of C++, so I can't really help with code analysis here.

> I don't know a lot of C++, so I can't really help with code analysis here.

Never mind, I sold myself a little short here. I've found the problem. Method `KFilePlacesModel::closestItem` doesn't return the hidden entries:

https://invent.kde.org/frameworks/kio/-/blob/v5.108.0/src/filewidgets/kfileplacesmodel.cpp#L733

    [...]
    for (int row = 0; row < d->items.size(); ++row) {
        KFilePlacesItem *item = d->items[row];

        if (item->isHidden() || isGroupHidden(item->groupType())) {
            continue;
        }
    [...]
    }

I confirmed it by

1. Disable checkbox "Hide section 'Devices'"
2. Repeat steps 2-4 in https://bugs.kde.org/show_bug.cgi?id=461872#c6

I found a problem in the related ticket https://bugs.kde.org/show_bug.cgi?id=466416 -- the steps to reproduce there aren't precise enough. Step 3 is "3. Unhide the section "Devices" in the "Places" panel.", but on the video recording attached to that ticket checkbox "Hide section 'Devices'" is enabled and I am using checkbox "Show All Entries" to make the overflowing section 'Devices' visible.

== Notes ==
All links to tag v5.108.0 in the frameworks/kio repository, because that's the version of KDE Frameworks I'm currently using.

This code comes from the following commits:

1. 74904f0 (KFilePlacesModel: ignore hidden places when computing closestItem, 2020-10-10) https://invent.kde.org/frameworks/kio/-/commit/74904f0cac872aac2423fe41adb115c3dc330ad5
2. eae7e8f ([KFilePlacesModel] Check group visibility in closestItem, 2021-06-19) https://invent.kde.org/frameworks/kio/-/commit/eae7e8f5c53b1ea8cf205ee061c6bea39a4a81a1

Good catch! I think we can fix this by adding a version of this function that doesn't skip hidden entries... I'll take a look.

Just some thinking out loud:

> Before adding an item to the menu, we check if any items for the same device ID exists and
> we remove them, so I don't see how this could happen.

I took a look at the git log, this logic comes from 2014: https://invent.kde.org/network/kdeconnect-kde/-/commit/90e9ded92655c26fbbe521982289998183631a50#b5e40816c0cc22bf4a042c2010f48a3423f93b0e_84_85

> the problem. Method `KFilePlacesModel::closestItem` doesn't return the hidden entries

Ten months ago (https://bugs.kde.org/show_bug.cgi?id=461872#c1) I commented that I _had_ to hide section 'Devices':

> This gets so bad, that I just have to hide the "Devices" section in Dolphin completely.
> 
> Question: is it possible that this is a Dolphin bug?

Maybe there was some other compounding bug (not in Dolphin, maybe in KIO?) that caused the entries not to be deleted? On the screenshot from matrix43547 -- https://bugs.kde.org/attachment.cgi?id=153763 -- the device names are in color of a "shown" section.

> All links to tag v5.108.0 in the frameworks/kio repository, because that's the version of KDE Frameworks I'm currently using.

This part of method `KFilePlacesModel::closestItem` hasn't changed since version 5.103.0, which is visible in video https://bugsfiles.kde.org/attachment.cgi?id=156717 which was recorded on 2023-02-25:

    https://invent.kde.org/frameworks/kio/-/blob/v5.103.0/src/filewidgets/kfileplacesmodel.cpp#L733

*** Bug 466416 has been marked as a duplicate of this bug. ***

Git commit d721f72a9bd98775dd91a4d00a9b5695484946eb by Albert Vaca Cintora.
Committed on 22/09/2023 at 21:51.
Pushed by albertvaka into branch 'master'.

Iterate KFilePlacesModel instead of using closestItem to remove SFTP entries

Fixes bug where we could miss entries due to `closestItem()` skipping hidden items. It is also more performant.

M  +7    -4    plugins/sftp/sftpplugin.cpp

https://invent.kde.org/network/kdeconnect-kde/-/commit/d721f72a9bd98775dd91a4d00a9b5695484946eb

Git commit de45a8017cff7df63ec0c967d0bfd8774afbddf8 by Albert Vaca Cintora.
Committed on 22/09/2023 at 21:53.
Pushed by albertvaka into branch 'release/23.08'.

Iterate KFilePlacesModel instead of using closestItem to remove SFTP entries

Fixes bug where we could miss entries due to `closestItem()` skipping hidden items. It is also more performant.

(cherry picked from commit d721f72a9bd98775dd91a4d00a9b5695484946eb)

# Conflicts:
#	plugins/sftp/sftpplugin.cpp

M  +7    -4    plugins/sftp/sftpplugin.cpp

https://invent.kde.org/network/kdeconnect-kde/-/commit/de45a8017cff7df63ec0c967d0bfd8774afbddf8