Thunar hangs when unmounting any disk volume in the Cinnamon environment, after 'libnotify*' is upgraded from 8.3 to 8.6

[nsleasy]

Distribution

Fedora 42

Package version

Cinnamon 6.4.9

Graphics hardware in use

No response

Frequency

Always

Bug description

• This occurs in the Cinnamon environment on Fedora, after upgrading the 'libnotify' package ('libnotify-bin' on Debian/Ubuntu) from 8.3 to 8.6

• Reference Fedora/Red Hat bug:
  https://bugzilla.redhat.com/show_bug.cgi?id=2372896

• This is not occurring now in the Mint Cinnamon environment, but likely will when 'libnotify-bin' is upgraded to 8.6

• Thunar unmounts volumes normally in all other environments, even when 'libnotify*' is upgraded (GNOME, KDE and Xfce)

Steps to reproduce

• Upgrade 'libnotify*' to version 8.6
• Open Thunar
• Unmount any non-system volume from Thunar
• Observe normal notification
• Thunar hangs for a long time

Expected behavior

• Upgrade 'libnotify*' to version 8.6
• Open Thunar
• Unmount any non-system volume from Thunar
• Observe normal notification
• Thunar returns control to user immediately

Additional information

I am reporting this as a downstream heads up, as you will likely encounter it in your environment soon.

[mtwebster]

I've broken down what looks like what was happening here in the commit message... the freeze was due to the dbus invocation never being 'completed' because of Cinnamon choking on an icon name in the image-path hint property when setting an additional image.

The reason it was trying to set an additional image in the first place is because with libnotify 0.86, notify_notification_update() will now end up setting that image-path hint internally at the same time it sets its icon_name property (which before now wasn't really used was only used with xdg portal notifications I think).

The way thunar is creating and updating its notifications, you'd end up with two identical icons of different sizes:

This looks pretty dumb, so to workaround thunar doing this (or any other app that ends up in this situation) we ignore a second icon if it would be identical to the app_icon:

Which brings us back to the original pre-0.86 look.

I think thunar should use NULL for icon_name in thunar_notify_progress() or use a real app (thunar) icon in thunar_notify_show().

I understand the challenge of this sort of library existing in the wild with different implementation versions and compatibility issues, but I think it'd have been clearer to just make update's icon argument 'unused' instead of now doing unexpected things.