https://bugs.kde.org/show_bug.cgi?id=394577
Bug ID: 394577
Summary: Panel / Task bar / Task Manager shows stub icon for
Firefox when Firefox is running; unable to customize
Firefox's icon
Product: frameworks-plasma
Version: 5.43.0
Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: libplasma
Assignee: notm...@gmail.com
Reporter: chadj...@gmail.com
Target Milestone: ---
Created attachment 112819
--> https://bugs.kde.org/attachment.cgi?id=112819&action=edit
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.
--
You are receiving this mail because:
You are watching all bug changes.
