Le 18/04/2023 à 16:08, Landry Breuil a écrit :
Le Tue, Apr 18, 2023 at 08:25:54AM +0200, Landry Breuil a écrit :
Le Sun, Apr 16, 2023 at 06:53:35PM +0200, Joel Carnat a écrit :
Le 16/04/2023 à 18:21, Landry Breuil a écrit :
Le Fri, Apr 14, 2023 at 09:49:38AM +0200, Joel Carnat a écrit :
Only the Exec part:
# diff /usr/local/share/applications/firefox.desktop
~/.local/share/applications/firefox.desktop
153c153
< Exec=firefox %u
---
Exec=firefox-default %u
200c200
< Exec=firefox -new-window
---
Exec=firefox-default -new-window
219c219
< Exec=firefox -private-window
---
Exec=firefox-default -private-window
Sorry, but i dont think that makes sense. Unless there's a
'firefox-default' script/wrapper in your $PATH, i doubt that can work.
or the /usr/local/share/applications/firefox.desktop file takes
precedence because ~/.local/share/applications/firefox.desktop has an
invalid entry for Exec
Well, I have no clue why it works. It just does (here) :D
I can even open ~/.local/share/applications/firefox.desktop, replace
"Exec=firefox-default %u" with "Exec=firefox %u", save the file, and the
icon changes on docklike. Reversing the change makes the icon appear on
docklike.
So i've had a proper look, and it is all caused by WM_CLASS being
firefox{,-esr}-default instead of just the program name.
I've build 113.0b4 & esr 102.10.0 with
MOZ_APP_REMOTINGNAME=${MOZILLA_PROJECT} in MAKE_ENV (directly in
mozilla.port.mk) and those binaries have their proper icon in
xfce4-docklike. You can try by installing them from
https://packages.rhaalovely.net/snapshots/amd64/
but there might be a 'better' fix. I see that for all mozilla ports
we're using
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-snap/firefox.desktop
as a source for our desktop file, but there's also
https://searchfox.org/mozilla-central/source/taskcluster/docker/firefox-flatpak/org.mozilla.firefox.desktop
and this one has StartupWMClass=firefox since
https://hg.mozilla.org/mozilla-central/rev/8bc2a43e9ac0f8521348db40df7b0f441c6392a2.
Can you try removing the '-default' suffixing horror, and just add
StartupWMClass=firefox (or thunderbird, or firefox-esr..) to your custom
desktop file and check this also fixes the problem ?
The firefox-flatpak desktop file has a bit more actions, more
translations, and seems better maintained upstream, so instead of
setting MOZ_APP_REMOTINGNAME in the build i'd rather switch to this
desktop file as a source for the one we install in the package.
My understanding of the root issue is that docklike relies on the
WM_CLASS value to match running processes, which doesnt work for mozilla
windows because of the -default suffix. You can see for yourself what
is the WM_CLASS for all existing windows using 'xlsclients', that might
also show other applications behaving weird.
Thinking more about it, i'm not sure fixing the desktop file is enough,
since that only might account for the browsers launched from clicking on
a proper launcher, and might not have the same behaviour with starting
"firefox" in a terminal.
More testing needed, but feedback on the rationale more than welcome !
Landry
I have tested various combination and long-story-short, nothing worked
except the dirty modification of Exec. StartupWMClass doesn't seem to be
taken in account, or at least WM_CLASS isn't changed (tested with xprop).
Using `firefox --class firefox` from xterm does show the proper icon.
You can then pin it on docklike. But it is pinned without the flags. You
have to edit the launcher to add "--class firefox". Then, clicking
docklike icon will start Firefox with the overwritten class and show the
icon.
I have noticed that when you modify the launcher from docklike, it
automatically modifies ~/.local/share/applications/firefox.desktop with
"Exec=firefox --class firefox %u".
Note that Thunderbird also has the StartupWMClass in the default desktop
file ; and the icon is ignored. I have also seen
/usr/local/share/applications/writer.desktop having "Exec=libreoffice7.5
--writer %U" in the stock file.
Joel C.
