Bug 394577

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.