1953034 - Sad smiley face in system notification area (when using swaybar)

Status: NEW

(Thunderbird :: OS Integration, defect)

Description

[Claudia Pellegrino]

Attachment: swappy-20250311_005349.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

Upgraded Thunderbird to 136.0 via system package manager.

Actual results:

While Thunderbird is running, a bright red frowny face appears in my system notification area and won’t go away until I quit Thunderbird. There’s no explanation as to what the face might mean. Interacting with the face via mouse doesn’t seem to do anything.

I have a predisposition to feel quite melancholic sometimes already. Continued presence of a sad face in my notification area is likely to exacerbate the issue, constantly reminding me that we are indeed living in difficult times.

Expected results:

No frowny face in my system notification area, preferably no face at all, like it used to be in Thunderbird versions prior to 136.

If developers insist that a frowny face must appear, the user should at least be given a chance to learn what the face means and how to make it go away.

Comment 1

[Magnus Melin [:mkmelin]]

What is your package manager / OS details?

It's not supposed to show like that. I suspect it's the system tray icon not working. See bug 1918035, and bug 1942125 dependencies.

Comment 2

[Claudia Pellegrino]

(In reply to Magnus Melin [:mkmelin] from comment #1)

What is your package manager / OS details?

It's not supposed to show like that. I suspect it's the system tray icon not working. See bug 1918035, and bug 1942125 dependencies.

I use pacman on Arch Linux. Here’s the package info and sources.

Comment 3

[Claudia Pellegrino]

Attachment: Output of dbus-monitor during the moment the sad face appears

Here’s the output of dbus-monitor during the moment the sad face appears.

The file path mentioned in the output, /usr/lib/thunderbird/chrome/icons/default/default256.png, seems consistent to this line of code.

I have double-checked that the file exists on my system. It contains a Thunderbird icon.

Comment 4

[Claudia Pellegrino]

Searching for sad face on GitHub, I managed to find one instance of the exact same sad face: swaywm/sway#7575

Quote:

After the latest system update, swaybar suddenly started displaying fcitx tray icon as red face instead of a keyboard.

Also possibly related: swaywm/sway#3799 (comment); quote:

Currently, for example, Quassel shows sad face instead of icon

Notably, one thing that all three issue reports have in common is that the people who filed them all use swaybar.

Comment 5

[Claudia Pellegrino]

Attachment: Output of strace (against the swaybar process) during the moment the sad face appears

I just ran an strace against the running swaybar process:

sudo strace -yZ -p "$(pgrep '^swaybar$')" 2> swaybar-strace-20250312_1301.log

Result (excerpt):

access("/usr/local/share/icons/hicolor/48x48@2/apps//usr/lib/thunderbird/chrome/icons/default/default256.png.svg", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/share/icons/hicolor/48x48@2/apps//usr/lib/thunderbird/chrome/icons/default/default256.png.png", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/share/icons/hicolor/48x48@2/apps//usr/lib/thunderbird/chrome/icons/default/default256.png.xpm", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/share/icons/hicolor/48x48/apps//usr/lib/thunderbird/chrome/icons/default/default256.png.svg", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/share/icons/hicolor/48x48/apps//usr/lib/thunderbird/chrome/icons/default/default256.png.png", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/local/share/icons/hicolor/48x48/apps//usr/lib/thunderbird/chrome/icons/default/default256.png.xpm", R_OK) = -1 ENOENT (No such file or directory)

See attachment for the whole capture.

Looks like there’s missing consensus as to whether the SNI specification allows fully qualified paths in the IconName field.

The specification suggests to me that it does not:

An icon can either be identified by its Freedesktop-compliant icon name, carried by this property of [sic!] by the icon data itself, carried by the property IconPixmap.

My interpretation: the value of the IconName property must be an icon name according to the icon naming spec. I don’t see that spec mention fully qualified paths at all. So I’d say a fully qualified path can’t possibly conform to the spec.

On the other hand, TB’s current implementation seems to assume that SNI allows for fully qualified paths, however I can’t find any part of the SNI or Freedesktop spec which would support that assumption.

Comment 6

[Manfred Knick]

SAME: Gentoo

[IP-] [ ] dev-libs/wayland-9999:0
[IP-] [ ] gui-libs/wlroots-9999:0.19
[IP-] [ ] gui-wm/sway-9999:0
[IP-] [ ] mail-client/thunderbird-136.0.1:0/stable

• starting TB, "Red Face" pops up
• ending TB, "Red Face" vanishes

HINT : lib <-> lib64 :
does not exist:
. -> /usr/lib/thunderbird/chrome/icons/default/default256.png
but does exist:
. -> /usr/lib64/thunderbird/chrome/icons/default/default256.png
containing TB icon

Comment 7

[Manfred Knick]

WORKAROUND:

• After evaluating multiple recommendations for setting icon_theme (e.g. "Adwaita") to no avail,
• I disabled the (irritating, not needed) TRAY in sway config file completely:
  tray_output none

man sway-bar(5) :
Swaybar provides a system tray where third-party applications may place icons.
The following commands configure the tray.
. . .
tray_output none|<output>|*
icon_theme <name>

@claui : enjoy a positive <smile> :
. . . . . status_command while echo "$(date +'%Y-%m-%d %X') + $'\U1F600' +" ; do sleep 1; done
HTH :-)

Comment 8

[Claudia Pellegrino]

@Manfred Thank you! I didn’t know about tray_output, and am happy to learn that I can actually disable the whole notification area.

Just for the record, my previous workaround until now was:

sudo cp -v /usr/lib/thunderbird/chrome/icons/default/default256.png{,.png}

which allows swaybar to find and display the proper icon that Thunderbird actually wanted to show up.

Comment 9

[Manfred Knick]

@claui : Personally, I also dislike all those distractions. || Thanks !

Comment 10

[Claudia Pellegrino]

To make Thunderbird conform to the SNI and icon naming spec, I propose that it always send both IconName and IconPixmap as follows:

1. Set IconName to thunderbird.
2. Set IconPixmap to the content of default256.png in ARGB32 format.

The SNI host side knows best which icon resolution it is supposed to pick, as it’s the one responsible for the notification area and therefore aware of its actual dimensions and resolution. Note that the SNI spec doesn’t seem to have an opinion yet as to whether the host should prefer IconName or IconPixmap in case it receives both in the same message. (There’s a FIXME at that point in the spec.)

I think it makes sense for an SNI host to prefer IconName. That’s how Swaybar implements it. It looks at IconName first and attempts to pick the best possible icon from the set of installed icons. Note that for IconName to produce an actual match, the user must be running Thunderbird from a distro-provided package, and the distro must package the set of icons under the proper name. If there’s no match for whatever reason (which can happen for a myriad of reasons, e.g. the user has no distro, or they’re running the binary from the Thunderbird website), then the SNI host has no choice but to use the pixels sent in IconPixmap.

@Magnus Melin, @Heather Ellsworth: am I missing something obvious from your point of view? Do you have other approaches in mind? Would you consider looking at a patch if I contributed one?

Comment 11

[Magnus Melin [:mkmelin]]

Sure, a patch would be great!
See https://developer.thunderbird.net/thunderbird-development/fixing-a-bug#creating-patches