Summary: | www-clients/firefox-bin: StartupWMClass missing in desktop file | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jan Henke <gentoo> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, gpopac, guillaume, leho, maxbritov, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Active Firefox window without StartupWMClass in firefox-bin.desktop file
Active Firefox window with StartupWMClass in firefox-bin.desktop file |
Description
Jan Henke
2021-08-11 12:48:24 UTC
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c208118615dc101a5098b4c2c05ac01027cb1dae You don't need to re-emerge. Just set > Icon=firefox-bin in /usr/share/applications/firefox-bin.desktop Unfortunately I have to reopen this bug. The commit you mentioned fixed the problem with the icon, still GNOME does not recognize the application belonging to the desktop file. For that to work, the line StartupWMClass=firefox needs to be present in the desktop file. I am confused a little bit: How is this related to the change introduced in firefox-bin-91? Only the wrapper was changed:
> --- firefox-bin.sh 2020-10-03 20:09:18.402975189 +0200
> +++ firefox-bin-r1.sh 2021-08-11 03:38:17.272732590 +0200
> @@ -29,18 +29,14 @@
> MOZ_EXTENSIONS_PROFILE_DIR="${HOME}/.mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}"
> MOZ_PROGRAM="${MOZILLA_FIVE_HOME}/${MOZ_FIREFOX_FILE}"
> APULSELIB_DIR="@APULSELIB_DIR@"
> -DESKTOP_FILE="firefox-bin"
>
> ##
> ## Enable Wayland backend?
> ##
> if @DEFAULT_WAYLAND@ && [[ -z ${MOZ_DISABLE_WAYLAND} ]]; then
> - if [[ -n "$WAYLAND_DISPLAY" ]]; then
> - DESKTOP_FILE="firefox-bin-wayland"
> + if [[ -n "${WAYLAND_DISPLAY}" ]]; then
> export MOZ_ENABLE_WAYLAND=1
> fi
> -elif [[ -n ${MOZ_DISABLE_WAYLAND} ]]; then
> - DESKTOP_FILE="firefox-bin-x11"
> fi
>
> ##
> @@ -75,7 +71,7 @@
> ##
> ## Disable the GNOME crash dialog, Mozilla has its own
> ##
> -if [[ "$XDG_CURRENT_DESKTOP" == "GNOME" ]]; then
> +if [[ "${XDG_CURRENT_DESKTOP}" == "GNOME" ]]; then
> GNOME_DISABLE_CRASH_DIALOG=1
> export GNOME_DISABLE_CRASH_DIALOG
> fi
> @@ -111,13 +107,5 @@
> export LD_LIBRARY_PATH="${APULSELIB_DIR:+${APULSELIB_DIR}:}${MOZILLA_FIVE_HOME}"
> export GTK_PATH="${MOZ_LIB_DIR}/gtk-3.0"
>
> -##
> -## Route to the correct .desktop file to get proper
> -## name and actions
> -##
> -if [[ $@ != *"--name "* ]]; then
> - set -- --name "${DESKTOP_FILE}" "$@"
> -fi
> -
> # Run the browser
> -exec ${MOZ_PROGRAM} "$@"
> +exec ${MOZ_PROGRAM} "${@}"
I am not sure either. I am just observing the behaviour stated above. There seems to be some heuristic in GNOME trying to match running applications with their desktop files. For some reason it worked before, but not any longer. I have observed the same problem in the past before the X11/Wayland wrapper scripts were added. In any way, setting the StartupWMClass in the desktop file fixes the problem. By the way the same problem also happened with thunderbird-bin. The missing icon issue also applies to www-client/firefox-91.0. (In reply to Stefan Radermacher from comment #5) > The missing icon issue also applies to www-client/firefox-91.0. This has already been addressed via https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6daee8e9bcf380a5e83d80578f0146c1bfff59c0 but without a rev bump to avoid rebuilding such a large package. Just set > Icon=firefox in /usr/share/applications/firefox.desktop (or rebuild package with up-to-date repo). Ah, I found https://forums.gentoo.org/viewtopic-t-1129209-start-0.html I still believe this is not necessary and wrong because it would clash with www-client/firefox. Could you please double check your icons? It could be possible that this showed up on your system, because you used wayland or x11 shortcut in previous releases (note that the wrapper routed you to these desktop files). But when you re-create/re-pin current shortcut, it should work again. Even without StartupWMClass. Created attachment 733577 [details]
Active Firefox window without StartupWMClass in firefox-bin.desktop file
Created attachment 733579 [details]
Active Firefox window with StartupWMClass in firefox-bin.desktop file
I have taken two screen shots to illustrate the difference. In both cases the same applications are running. Notice that without the StartupWMClass in the desktop file, the currently running Firefox window has no icon and hitting the shortcut for the application starts a new instance. While when it is defined, the running instance is associated with the favourite (first icon on the bar) and hitting the shortcut brings the focus back to the running window (as intended). Yes, there could be a collision between the -bin and non-bin in that regard, but I see no real use case in having both. On the other hand, right now it is broken in regards to the interaction between the desktop environment and a running instance (if I wouldn't add StartupWMClass manually right now) So this is why my Alt-TAB switcher lost Firefox icon. Confirmed, adding "StartupWMClass=firefox" worked well to restore it for www-client/firefox-bin. metoo Works fine in Xorg session, but not under Wayland session. Both firefox-bin and thunderbird-bin This was driving me mad for ages, and adding that sorts it for me. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=12e24437c4f01511acebb8fdcb717d5c4bdbccd6 commit 12e24437c4f01511acebb8fdcb717d5c4bdbccd6 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-02-08 08:54:49 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-02-08 09:10:58 +0000 www-client/firefox-bin: add 91.6.0 Bug: https://bugs.gentoo.org/807691 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox-bin/Manifest | 97 ++++++ .../firefox-bin/files/firefox-bin-r3.desktop | 1 + www-client/firefox-bin/firefox-bin-91.6.0.ebuild | 387 +++++++++++++++++++++ 3 files changed, 485 insertions(+) Thanks for fixing this annoying behaviour for Firefox. Thunderbird-bin has the same problem, where it needs the line StartupWMClass=thunderbird in the desktop file. Can you fix that too, or does it need a new bug? Hey, I will when thunderbird-91.6.0 comes out (tomorrow most likely). To _close_ this bug I'd like to know how this can be fixed with wayland? For me, adding this line also fixed the problem with GNOME under wayland. Others have commented that it would not work with wayland, but I cannot reproduce. (In reply to Jan Henke from comment #17) > For me, adding this line also fixed the problem with GNOME under wayland. > Others have commented that it would not work with wayland, but I cannot > reproduce. It works fine with Wayland. Have been doing this months. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=50183945adf00b222451a8bdd141d40a685ce79a commit 50183945adf00b222451a8bdd141d40a685ce79a Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-02-09 11:22:03 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-02-09 13:35:14 +0000 mail-client/thunderbird-bin: add 91.6.0 Closes: https://bugs.gentoo.org/807691 Signed-off-by: Joonas Niilola <juippis@gentoo.org> mail-client/thunderbird-bin/Manifest | 65 ++++ .../files/icon/thunderbird-bin-r2.desktop | 1 + .../thunderbird-bin/thunderbird-bin-91.6.0.ebuild | 335 +++++++++++++++++++++ 3 files changed, 401 insertions(+) |