I would suggest to add `StartupWMClass=thunderbird` to the desktop file.

See: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5739

You can verify this by using looking glass tool in gnome-shell (Alt-F2, type `lg` and press enter). By listing "Windows", you could find that the 115.2.0-3 version of thunderbird has no desktop file linked to that window (shown as "<untracked>"). This also causes it losing proper icon in GNOME's dock.

Instead of adding a symlink inside package, adding `StartupWMClass` field inside desktop file sounds like a better idea.

Of course. Adding the soft link is not a proper solution. It was just to give a hint as were the problem is.

Adding StartupWMClass=thunderbird fixes the issue. Thank you Keyu Tao.

Does someone from Archlinux have to fix it?

Ideally it should go upstream...but the Arch pkg could possibly be tweaked in the meanwhile.

We generally try to not maintain patches outside of upstream unless we got reasons to. So upstream it for now and wait a bit to see if they will implement it.

Did some simple search and found some related upstream bugs:

- ~~https://bugzilla.mozilla.org/show_bug.cgi?id=1107281 (Opened in 2014)~~ No it is about Firefox
- https://bugzilla.mozilla.org/show_bug.cgi?id=1610305 (Opened in 2020)

Found it! This bug should have been fixed by upstream 2 months ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1843045

The fix: https://hg.mozilla.org/comm-central/rev/ce1f17a138e651effb441e8abee90dcc344dda8b

```
--- a/taskcluster/docker/thunderbird-flatpak/org.mozilla.Thunderbird.desktop.jinja2
+++ b/taskcluster/docker/thunderbird-flatpak/org.mozilla.Thunderbird.desktop.jinja2
@@ -10,16 +10,17 @@ GenericName={{ strings.get_message("en-U
{%- endfor %}
Exec=thunderbird %u
Terminal=false
Type=Application
Icon=org.mozilla.Thunderbird
Categories=Network;Email;
MimeType=message/rfc822;x-scheme-handler/mailto;text/calendar;text/vcard;text/x-vcard;x-scheme-handler/webcal;x-scheme-handler/webcals;x-scheme-handler/mid;
StartupNotify=true
+StartupWMClass={{ wmclass }}
Actions=ComposeMessage;OpenAddressBook;

[Desktop Action ComposeMessage]
Name={{ strings.get_message("en-US", "flatpak-desktop-action-compose") }}
{%- for line in translate("Name", "flatpak-desktop-action-compose") %}
{{ line }}
{%- endfor %}
Exec=thunderbird -compose
```

Note that the actual desktop file they use is generated by jinja2 instead of directly using taskcluster/docker/thunderbird-flatpak/org.mozilla.Thunderbird.desktop.

The fix that you refer to landed in 115.1.0, but is only for flatpack builds.

The thing is that it worked correctly in version 115.2.0-1 with the thunderbird.desktop file, but in version 115.2.0-3 the file name was changed to org.mozilla.Thunderbird.desktop. And in both files there is no StartupWMClass directive in the desktop file.

I understand that the difference between 115.2.0-1 and 115.2.0-3 is only that Archlinux builds it differently and that it is the same source (115.2.0), correct? That is why I deduced that the problem was introduced by Archlinux.

Please read PKGBUILD of thunderbird Ben:

https://gitlab.archlinux.org/archlinux/packaging/packages/thunderbird/-/blob/a1a72d04a47bb693babb2d6d2f754675003f90a2/PKGBUILD#L133

The desktop file it uses comes from upstream's Flatpak builds. The problem now is that, upstream is using a jinja2 template (with bug fixed) to construct desktop file, while they leave a complete desktop file (without StartupWMClass) at the same directory -- seem like they forget to remove or update this file.

The simplest solution would be, to install the file as thunderbird.desktop:

install -Dm 644 -T comm/taskcluster/docker/tb-flatpak/org.mozilla.Thunderbird.desktop "$pkgdir/usr/share/applications/thunderbird.desktop"

I have created a bug report to upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1852091.

Test with 115.2.2-1 please.

I have tested thunderbird 115.2.2-1 in Extra-Testing and I think that it has fixed this bug.