Created attachment 151358 [details] favorites list STEPS TO REPRODUCE 1. install Firefox from distro repositories 2. add Firefox to Favorites list of kickoff 3. go to https://www.mozilla.org/en-US/firefox/new/ and download .tar.bz2 archive of firefox 4. extract the downloaded archive to Home 5. restart Plasma with 'plasmashell --replace', or logout and login 6. open kickoff and OBSERVED RESULT Icon of firefox disappeared from Favorites list and from Internet submenu. Please see the attached screenshots. EXPECTED RESULT no icon should disappear after the provided steps SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.25.80 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Graphics Platform: Wayland
Created attachment 151359 [details] internet submenu
Did it install icons to ~/.local/share/icons?
Possibly Firefox icons are installed to ~/.local/share/icons when I install Firefox from neon/ubuntu repos. The icons reappear in my kickoff after deleting 'firefox' folder (created after extracting firefox-<version>.tar.bz2 archive) from Home and re-login.
That all makes sense. The XDG icon inheritance logic looks for icons in your home folder before looking in /usr/share/icons. So it seems like the icons in your home folder got picked first, and for some reason they weren't able to be displayed. Can you attach the contents of ~/.local/share/icons/firefox?
the directory does not exist $ ls ~/.local/share/icons/firefox ls: cannot access '/home/stalker/.local/share/icons/firefox': No such file or directory
can also reproduce with smb4k 1. install smb4k and make sure its icon is present under 'Utilities' submenu of kickoff 2. create a folder called 'smb4k' in Home 3. restart Plasma by running 'plasmashell --replace' with krunner Result: icon of smb4k disappeared from kickoff
same with okular 1. install Okular and make sure its icon is present in kickoff 2. create a folder called 'okular' in Home 3. restart Plasma by running 'plasmashell --replace' with krunner Result: icon of Okular disappeared from kickoff
Wow, I can reproduce for all apps.
Wow, crazy. Can reproduce 100% in Kickoff for all app names I try. For example creating ~/system-file-manager makes Dolphin's icon in Kickoff become blank.
Found it. In the Kicker model, appentry.cpp has this: QIcon AppEntry::icon() const { if (m_icon.isNull()) { if (QFileInfo::exists(m_service->icon())) { m_icon = QIcon(m_service->icon()); } else { m_icon = QIcon::fromTheme(m_service->icon(), QIcon::fromTheme(QStringLiteral("unknown"))); } } return m_icon; } if (QFileInfo::exists(m_service->icon())) { is returning true here. If I comment all of that out, the problem stops happening. This code seems weird. I hven't figured out its purpose yet.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2034
Git commit 57d55e386a1f66390704c3a166d6c7fcc8120a7c by Nate Graham. Committed on 22/08/2022 at 16:06. Pushed by ngraham into branch 'master'. applets/kicker: fix app icon loading logic to better handle relative paths ba44b69abf82b1236ffab7d8683728c142d30c52 added logic to handle apps that use an absolute path in their .desktop file to define their icon, which works. However in the process it introduced a subtle bug: if the icon is not an absolute path and it's just a normal icon name, when QFileInfo::exists() checks for the existence of that string, it will treat it as a relative file path and therefore look for it in the current working directory, which is typically the user's homedir. If it finds something, it will go down the wrong code path and end up returning a blank QIcon. This can be verified by adding a folder with the name of an app icon into ~ and restarting plasmashell; that app in Kickoff will have a blank icon. To fix this, the icon loading code now first checks whether the icon returned by m_service->icon() is actually an absolute path. If not, it skips the logic to look for it on disk and goes straight to the codepath that looks for an icon with that name in the icon theme. To minimize disk reads, it checks for absolute-file-path-ness by inspecting the string returned by m_service->icon() rather than using QFileInfo::isAbsolute(), because this is a hot code path and most icons will not have relative paths, so checking the disk for every one of them would be a waste of resources. FIXED-IN: 5.24.7 M +16 -3 applets/kicker/plugin/appentry.cpp https://invent.kde.org/plasma/plasma-workspace/commit/57d55e386a1f66390704c3a166d6c7fcc8120a7c
Git commit 1a74e6237062e5c6d583f0afcd53d21bef3ffd98 by Nate Graham. Committed on 22/08/2022 at 16:20. Pushed by ngraham into branch 'cherry-pick-57d55e38'. applets/kicker: fix app icon loading logic to better handle relative paths ba44b69abf82b1236ffab7d8683728c142d30c52 added logic to handle apps that use an absolute path in their .desktop file to define their icon, which works. However in the process it introduced a subtle bug: if the icon is not an absolute path and it's just a normal icon name, when QFileInfo::exists() checks for the existence of that string, it will treat it as a relative file path and therefore look for it in the current working directory, which is typically the user's homedir. If it finds something, it will go down the wrong code path and end up returning a blank QIcon. This can be verified by adding a folder with the name of an app icon into ~ and restarting plasmashell; that app in Kickoff will have a blank icon. To fix this, the icon loading code now first checks whether the icon returned by m_service->icon() is actually an absolute path. If not, it skips the logic to look for it on disk and goes straight to the codepath that looks for an icon with that name in the icon theme. To minimize disk reads, it checks for absolute-file-path-ness by inspecting the string returned by m_service->icon() rather than using QFileInfo::isAbsolute(), because this is a hot code path and most icons will not have relative paths, so checking the disk for every one of them would be a waste of resources. FIXED-IN: 5.24.7 (cherry picked from commit 57d55e386a1f66390704c3a166d6c7fcc8120a7c) M +16 -3 applets/kicker/plugin/appentry.cpp https://invent.kde.org/plasma/plasma-workspace/commit/1a74e6237062e5c6d583f0afcd53d21bef3ffd98
Git commit ffd76192f35ddc74fcd63fbe77203894b14068ad by Nate Graham. Committed on 22/08/2022 at 16:20. Pushed by ngraham into branch 'Plasma/5.25'. applets/kicker: fix app icon loading logic to better handle relative paths ba44b69abf82b1236ffab7d8683728c142d30c52 added logic to handle apps that use an absolute path in their .desktop file to define their icon, which works. However in the process it introduced a subtle bug: if the icon is not an absolute path and it's just a normal icon name, when QFileInfo::exists() checks for the existence of that string, it will treat it as a relative file path and therefore look for it in the current working directory, which is typically the user's homedir. If it finds something, it will go down the wrong code path and end up returning a blank QIcon. This can be verified by adding a folder with the name of an app icon into ~ and restarting plasmashell; that app in Kickoff will have a blank icon. To fix this, the icon loading code now first checks whether the icon returned by m_service->icon() is actually an absolute path. If not, it skips the logic to look for it on disk and goes straight to the codepath that looks for an icon with that name in the icon theme. To minimize disk reads, it checks for absolute-file-path-ness by inspecting the string returned by m_service->icon() rather than using QFileInfo::isAbsolute(), because this is a hot code path and most icons will not have relative paths, so checking the disk for every one of them would be a waste of resources. FIXED-IN: 5.24.7 (cherry picked from commit 57d55e386a1f66390704c3a166d6c7fcc8120a7c) M +16 -3 applets/kicker/plugin/appentry.cpp https://invent.kde.org/plasma/plasma-workspace/commit/ffd76192f35ddc74fcd63fbe77203894b14068ad
Git commit f0a3a400d63939e70004e6df76536ce538b428c3 by Nate Graham. Committed on 22/08/2022 at 16:20. Pushed by ngraham into branch 'Plasma/5.24'. applets/kicker: fix app icon loading logic to better handle relative paths ba44b69abf82b1236ffab7d8683728c142d30c52 added logic to handle apps that use an absolute path in their .desktop file to define their icon, which works. However in the process it introduced a subtle bug: if the icon is not an absolute path and it's just a normal icon name, when QFileInfo::exists() checks for the existence of that string, it will treat it as a relative file path and therefore look for it in the current working directory, which is typically the user's homedir. If it finds something, it will go down the wrong code path and end up returning a blank QIcon. This can be verified by adding a folder with the name of an app icon into ~ and restarting plasmashell; that app in Kickoff will have a blank icon. To fix this, the icon loading code now first checks whether the icon returned by m_service->icon() is actually an absolute path. If not, it skips the logic to look for it on disk and goes straight to the codepath that looks for an icon with that name in the icon theme. To minimize disk reads, it checks for absolute-file-path-ness by inspecting the string returned by m_service->icon() rather than using QFileInfo::isAbsolute(), because this is a hot code path and most icons will not have relative paths, so checking the disk for every one of them would be a waste of resources. FIXED-IN: 5.24.7 (cherry picked from commit 57d55e386a1f66390704c3a166d6c7fcc8120a7c) M +16 -3 applets/kicker/plugin/appentry.cpp https://invent.kde.org/plasma/plasma-workspace/commit/f0a3a400d63939e70004e6df76536ce538b428c3