When running firefox-bin on Plasma 6 RC2 Wayland, it seems that it gets a generic placeholder Wayland icon in the alt-tab switcher and the title bar. It is however associated with the correct icon in the task manager. A workaround for this is to add `--name=firefox-bin` to the launch parameters. This presumably allows KDE to find the correct desktop file, and then set the correct icon etc. (I'm not an expert on how all this stuff works, sorry!) This should probably be handled in the startup script for firefox-bin, so that it will behave correctly? Although some forum posts I found seemed to indicate that `--name=firefox` should be correct, so I'm a bit confused. https://forums.gentoo.org/viewtopic-p-8798292.html https://forums.gentoo.org/viewtopic-t-1129209-start-0.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1826330 probably related. I wanted to set up a VM with KDE to test this, but I most likely won't have time for that.
I can reproduce the bug on KDE 5 as well. I can't recall exactly when it broke but I recently switched from firefox to firefox-bin and it worked before with firefox. So it does not seem to be related to KDE 6 exclusively.
PS: I can confirm that the proposed workaround (appending `--name=firefox-bin` to the arguments) fixes the icon.
Is that still a problem?
Yes, I just confirmed that this is still a problem on KDE 6. The workaround (--name=firefox-bin) still fixes the issue. www-client/firefox-bin-130.0.1 kde-plasma/plasma-workspace-6.1.4-r1
(In reply to Richard Steinmetz from comment #5) > Yes, I just confirmed that this is still a problem on KDE 6. Just in case that wasn't clear yet: This is not a KDE Plasma problem. It is the mismatch of the www-client/firefox-bin package's .desktop file name against the app-id. This is also evident as the problem is being worked around by a side-by-side installed www-client/firefox (non-bin). All of a sudden, the "correct" icon is being used. As I was just explaining to another project: https://github.com/Brewtarget/brewtarget/issues/933
Hmm, IIRC the broken icon is wayland related and working fine in X. But since the package has a 'wayland' use flag, how about something like: if use wayland ; then use_wayland="true" local exec_command="${PN} --name=firefox-bin" else local exec_command="${PN} --name=firefox" fi then again as asturm says, I may have it accidentally working even in X due to source-built firefox being installed simultaneously.
Would it be possible to move forward with Joonas suggestion? In my opinion, a simple if condition like the one proposed is acceptable. It would not patch source code or anything so the impact is limited. The exec_command local variable even exists already. Thanks!
(In reply to Joonas Niilola from comment #7) > Hmm, IIRC the broken icon is wayland related and working fine in X. It is just as wrong in X, with the icon just being the most visible thing that breaks. (In reply to Joonas Niilola from comment #7) > if use wayland ; then > use_wayland="true" > local exec_command="${PN} --name=firefox-bin" > else > local exec_command="${PN} --name=firefox" > fi Why even bother making this build time conditional? desktop profile has USE=wayland enabled by default, so everyone starting an X11 session would get --name=firefox-bin anyway?
(In reply to Andreas Sturmlechner from comment #9) > Why even bother making this build time conditional? desktop profile has > USE=wayland enabled by default, so everyone starting an X11 session would > get --name=firefox-bin anyway? Having "desktop profile" enabled doesn't dictate everything. I don't have wayland use flag on, despite using desktop profile. I don't have problems either. Funny...
(In reply to Joonas Niilola from comment #10) > (In reply to Andreas Sturmlechner from comment #9) > > Why even bother making this build time conditional? desktop profile has > > USE=wayland enabled by default, so everyone starting an X11 session would > > get --name=firefox-bin anyway? > > Having "desktop profile" enabled doesn't dictate everything. I don't have > wayland use flag on, despite using desktop profile. I don't have problems > either. Funny... Right. There may be non-desktop users enabling USE=wayland as well. What are you trying to argue for here?
(In reply to Andreas Sturmlechner from comment #11) > Right. There may be non-desktop users enabling USE=wayland as well. What are > you trying to argue for here? Is that somehow related to firefox though? I'm trying to say, as far I understand what the problem is, pairing it with the wayland use flag seemed like a good solution. But it was a question, I'm not familiar with KDE or wayland. Let me know what the proper fix it, without breaking firefox-bin on X.
(In reply to Joonas Niilola from comment #12) > (In reply to Andreas Sturmlechner from comment #11) > Let me know what the proper fix it, without breaking firefox-bin on X. What is it breaking on X?
(In reply to Andreas Sturmlechner from comment #13) > What is it breaking on X? I don't know, because I haven't tried. I do know the current one works in X. So of course I expect something to break if I change a working solution? Then again, maybe X is smarter about it and can work both ways. But like I said, haven't tried with the proposed --name flag, yet.
If you believed that this would break something in X, then your proposed solution (In reply to Joonas Niilola from comment #7) > if use wayland ; then > use_wayland="true" > local exec_command="${PN} --name=firefox-bin" > else > local exec_command="${PN} --name=firefox" > fi would be just as broken since any desktop profile user *not* disabling USE=wayland (the majority, probably?) may at any time start into an X11 session anyway? If you don't believe my words that this is broken on X as well [even if the *icon* is shown], then I'm not sure more words will help. Maybe you didn't see my link, let me refer to upstream again here: https://nicolasfella.de/posts/fixing-wayland-taskbar-icons/ https://nicolasfella.de/posts/importance-of-desktop-file-mapping/ https://specifications.freedesktop.org/desktop-entry-spec/latest/file-naming.html
I did read them the first time you linked them :) but they just fostered it to look like it's KDE/wayland problem (although https://nicolasfella.de/posts/importance-of-desktop-file-mapping/ does explain benefits on x11 as well). I'm fine adding the '--name=firefox-bin' unconditionally in every case. Firefox should have better X/wayland detection by now, too, so maybe we ought to get rid of the use flag completely. At least in my setup that didn't break anything, but could also be due to me having the source-built variant installed as well. I really hope to get a working vm setup again to test these on different environments.
I just saw the following block in the ebuild which also needs to be considered. Although I'm not sure why there is a difference between both channels. Perhaps, the default value differs in both? if [[ -n ${MOZ_ESR} ]] ; then local exec_command="${PN} --name=firefox" else local exec_command="${PN}" fi The above block could be reduced to the following: local exec_command="${PN} --name=${PN}" Do you agree? I don't see disadvantages to always setting the name to firefox-bin (regardless of X, wayland, esr or rapid) other than some users' KDE window rules breaking.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b64d67547883812ba525414a5ad81c9d9f65c90b commit b64d67547883812ba525414a5ad81c9d9f65c90b Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2025-02-21 09:10:18 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2025-02-21 09:10:18 +0000 www-client/firefox-bin: match .desktop filename with app --name Closes: https://bugs.gentoo.org/924453 Signed-off-by: Joonas Niilola <juippis@gentoo.org> .../{firefox-bin-128.7.0.ebuild => firefox-bin-128.7.0-r1.ebuild} | 7 +------ .../{firefox-bin-135.0.1.ebuild => firefox-bin-135.0.1-r1.ebuild} | 7 +------ 2 files changed, 2 insertions(+), 12 deletions(-)
