Created attachment 112819 [details] Plasma 5 panel/taskbar showing stub icon for running Firefox Hello, When I start Firefox, the following happens in the panel/taskbar/task manager: - A tab (task?) appears for Firefox. - The Firefox icon appears on the tab for a few frames. - There is a very brief stutter, as if Firefox closed and reopened. - The Firefox icon is immediately replaced with what appears to be a stub icon. - The stub icon will remain until I close Firefox or otherwise dismiss that tab/task. It looks like this: https://photos.app.goo.gl/jPdQWi2crItDioED3 (This image is also attached.) (The icon I see looks to me like a dark gray piece of paper with a folded corner and a light gray iconified app window in the middle, with an exclamation point in the middle of the window.) This is very frustrating because the stub icon is non-distinct, so it kept looking like I couldn't bring Firefox up by clicking on it in the panel/taskbar, yet Firefox was there all along, hiding in the sea of gray. I try various hocus pocus from bug reports and forum posts across the internet. For example, I used kmenuedit to set Firefox's icon to firefox again, because some users seemed to experience success with that and infer that the assignment of that icon must do more than merely change the icon that appears in the application launcher. None of those cute tricks worked. Then I found this bug: https://bugs.kde.org/show_bug.cgi?id=353733 which told me that the Firefox icon was removed from the Breeze theme due to some kind of legal fears. That was back in *2015*, so I was slightly disappointed that a KDE dude hasn't talked to a Mozilla dude and reached an agreement to solve the problem sometime before 2018. It seems like something that would be on the right side of cost-benefit: sure this may seem minor, but it probably affects an enormous amount of users in a very prominent way, and it might be very easy to fix. But that's OK. The rest of my Plasma 5 experiences is going very well, and I have a Firefox icon on my computer. Probably more than one, even! Firefox comes with its own icon(s), after all. So I set about injecting the Firefox icon back into its place. I learned that there are various firefox.png instances in the /usr/share/icons/hicolor/NNxNN/apps directories. I also learn that icons can be added to the stack without disturbing the root system by building corresponding directories in ~/.local/share/icons/*. I'm using the Breeze icon theme, so I figure I need ~/.local/share/icons/breeze to contain at least the firefox.png's from the hicolor theme (whatever that is). The first experiment involves me creating a symlink... /usr/share/icons/hicolor -> ~/.local/share/icons/breeze ... so that, per my naive understanding at the time, the icon set available would essentially be the union of the two, with the .local ones overriding the /usr ones in the event of conflict. And it works!... almost. The Firefox icon reappeared, but then all of the other icons (Dolphin folder icons, system settings icons, many things in the application launcher and settings menus, and so on) went completely invisible. Not even a stub graphic remains. So that's no good either, but it's encouraging at least. Next I try to be more surgical. I delete that symlink and manually create the ~/.local/share/icons/breeze folder and subfolders, then I create individual symlinks for every firefox.png file. Maybe there were a bunch in ~/.local that were overriding /usr icons, but couldn't be rendered for some reason. Well, that didn't work at all, and the system went back to the original condition where most icons were fine and Firefox had a stub graphic for an icon. I then start trying to figure out what made the one directory display the icon I wanted when the other directory did not. This involved learning about the Icon Theme layout; this site was my primary reference: https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html Things I tried: - Create an index.theme file in ~/.local/share/icons/breeze folder. - Iterate on the index.theme file and occasionally bounce back-and-forth between having a working Firefox icon and having working system icons. I run 'gtk-update-icon-cache' after any and all changes. - Rename ~/.local/share/icons/breeze to ~/.local/share/icons/user and change my icon theme to this new user theme in System Settings -> Appearance -> Icons. I use the 'Inherits=breeze' declaration to make it (in principle) pull the Breeze icons. - Add ~/.local/share/icons/user/apps/NN directories to mirror what appears in /usr/share/icons/breeze. These are just symlinks to the NNxNN/apps directories. Update index.theme and then run 'gtk-update-icon-cache'. - I try setting the index.theme directory declarations to "scalable" and have the ranges cover all possible icon sizes that could matter for this. This seems to be used for .svg mostly, but the way the lookup algorithm is described seems to suggest it could work for any image file, and the program or framework looking up the icon would be responsible for actually scaling the image. It didn't help. You can see my last index.theme attempt here: https://pastebin.com/jQ9DeU56 Here is a more visual view of the directory structure I used to create my icon theme: https://pastebin.com/Tu8XcHUS From what I read about the icon theme standard on the freedesktop.org site, inheritance should be able to solve this problem, and one of my above steps should have fixed the issue. But it just won't do the described inheritance behavior, despite acknowledging my customizations. Another interesting note: when I right click on the Firefox task in the panel and tell it to "Start New Instance", it gives me an error message: Title: "Sorry -- Plasma" Text: "Could not find the program '/opt/firefox/firefox'" Button: OK Indeed, /opt/firefox/firefox doesn't exist. But I don't understand why it would exist or why creating a new instance would look there particularly. This makes me wonder if Firefox's startup process involves temporarily writing an executable or script to /opt/firefox/firefox, executing that to actually run the browser, and then deleting that executable/script after it has started executing from memory (perhaps as a security feature?), and maybe Plasma or whatever responsible theming engine is unable to follow this indirection completely--it does at least follow partially because the task widget persists. I am running on X, not Wayland. (The Wayland ecosystem seems to lack a convincing replacement for X-forwarding as of yet.) I have probably spent way too much time on this, but hopefully this will at least be a useful user experience report, if not a helpful bug report :) ("I totally could have stopped at any time. Really. Honest. Why are you looking at me like that...") Thank you for reading and for making a very pleasing and productive desktop environment.
This is caused by Firefox being incorrectly installed. Here's how this generally works on Linux: * The app installs a NAME.desktop file * X11: The app sets the WM_CLASS of its window to NAME * Wayland: The app sets the appid of its window to NAME.desktop * The .desktop file contains an Icon=SOMETHING line * The app installs an icon named SOMETHING in hicolor, or the current icon them (or anything in its inheritance hierarchy, which eventually hits hicolor) contains a SOMETHING icon Well-behaved and well-installed apps get all of this right. Various apps do not get it right, so the Task Manager code has numerous heuristics and fallbacks to work around their bugs - digging into other metadata, matching up executable names from /proc to Exec= keys in .desktop files, etc. It appears none of those do the right thing on your system. The goal would be to work towards the optimal scenario painted above. The /opt stuff makes me think you have a stray firefox .desktop file in your system somewhere that takes precedence and misleads everything. You can use xprop to get the WM_CLASS for the window. (PS.: Also a Firefox user here fwiw :) I need to close this as WORKSFORME for now because there's nothing I can really do, but if you've worked through the above pointers and still think you're hitting some sort of real bug, feel free to reopen and we continue.
Thanks! That process overview is excellent, and it's good to know about those fallback heuristics. I will use that information to investigate more.
Problem seems fixed after removing the ~/.local/share/applications/firefox.desktop file. Specifically, I moved it to a backup file like so: cd ~/.local/share/applications mv firefox.desktop firefox.desktop.bak-2018.11.19 It took me a while to revisit this problem, but inspiration hit: I think Eike's mention of /opt being odd and an incorrect .desktop file were the hint I needed. The contents of the firefox.desktop file looked like this: [Desktop Entry] Exec=/opt/firefox/firefox Icon=application-x-executable Name=firefox Type=Application This seems a likely candidate for explaining why plasma was looking for the /opt/firefox/firefox file that did not exist (the /opt/firefox directory also doesn't exist). I'm not sure I understand specifics about the mechanisms involved, but I can see how telling KDE/plasma to open a non-existent executable might confuse it. Or perhaps the .desktop was outdated and accidentally overrode metadata from more well-updated system files. Whatever the possibilities, that file seemed like a source of problems, and removing it fixed this problem. I'm also not sure how I ended up with the state in the first place. Maybe Firefox really did live in /opt/firefox/firefox at one point in history, and then an upgrade at some point moved it elsewhere, but without updating the .desktop file (and it's hard to expect a package manager or install script to always perfectly handle updates to user configuration). Maybe these are remnants of some workaround from days past. I'm not too worried about it because of how isolated this seems. Thanks for the help Eike Hein!
Glad you were able to work it out & thanks for the ticket update!