thunderbird-esr-bin

Binary-tarball ESR package (Mozilla releases, per-arch source arrays for x86_64/pentium4/i686). Routine updates are a straight pkgver bump + updpkgsums + .SRCINFO regen – no build-system quirks.

2026-07-22: version bump + AUR-reported desktop/icon fix

Bumped 140.12.1 -> 140.13.0 (routine nvchecker UPD flag).

While in there, checked FEEDBACK.txt for this package (per updated workflow – check AUR comments for every touched package, not just UPD-flagged ones) and found three related comments about the taskbar/icon not showing correctly under GNOME/Wayland (generic “Wayland” icon shown instead of Thunderbird’s), spanning 2025-12-17 to 2026-07-21:

• GuillaumeZITTA (2025-12-17) reported manually adding StartupWMClass=thunderbird-esr to /usr/share/applications/thunderbird.desktop fixed taskbar grouping (e.g. “Dash to Panel” GNOME extension not recognizing the window).
• MaKaNu (2026-01-02) reported the installed desktop file’s Icon= points at thunderbird, but the icon doesn’t show – symptom consistent with GNOME Shell/Wayland matching a running window to its launcher via StartupWMClass (or WM_CLASS) rather than reading the window’s own icon; without a match it falls back to a generic icon.
  • Note: GuillaumeZITTA’s report describes editing thunderbird.desktop directly (the installed name), not this package’s source file thunderbird-esr-bin.desktop – the same filename issue guoxh’s comment below points at. Worth revisiting if this fix alone doesn’t fully resolve it.
• guoxh (2026-07-21) suggested instead renaming the installed .desktop file itself to thunderbird-esr.desktop to fix the icon.

Applied the lower-risk, user-confirmed fix: added StartupWMClass=thunderbird-esr to thunderbird-esr-bin.desktop (this package’s source .desktop file, installed as thunderbird.desktop per package()’s $_pkgname.desktop naming – unchanged). Did not rename the installed desktop filename (guoxh’s suggestion) – that’s a bigger, unconfirmed change (would need to also update the install= script, conflicts=, and any icon-cache MIME associations) and the StartupWMClass line alone is the one an actual user confirmed fixed the symptom.

If a future AUR comment says the icon/taskbar issue persists after this fix, revisit guoxh’s rename suggestion next.