notifications from some applications don't obey timeout rules

[Jazoray]

i have set my timeouts to 30 for all urgencies.

however, notifications from some applications, for example discord, disappear very quickly. approximately after just 3 seconds.

[dddlr]

Can confirm for both Discord Canary and the stable version of Discord. Neither

[global]
    timeout = 30

nor

[discord_canary]
    appname = Discord Canary
    background = "#36393E"
    format = "<b>%s</b>\n%b"
    timeout = 30

[discord]
    appname = Discord
    background = "#1E2124"
    format = "<b>%s</b>\n%b"
    timeout = 30

appear to affect the approx. 3-second timeout used.

Edit: I’m using Dunst 1.1.0

[Jazoray]

i think this happens whenever any notification-sending app requests a custom timeout for its notification. it works with notify-send -t <number> too. it seems to override any global timeout setting.

this seems to be a feature supported by the libnotify protocol.

this is probably not a bug then but a feature request.

[dddlr]

Oddly enough, when I use
notify-send -t 100 "blehp"
and keep the keyboard or mouse active, the message disappears in approx. 3 seconds, not 100 milliseconds.

notify-send -t 10000 "blehp"
disappears in approx. 11 seconds.

[knopwob]

As someone else stated before, the app can send a custom timeout, which overrides the timeout from the [global] section in the config. Eventhough the protocol works with milliseconds, dunst internally uses seconds, so the timeout send by the app will be rounded to the next second.

so notify-send -t 100 "blehp" should timeout after one second. This might get extended to 2 seconds, due to some other rounding stuff.

But the timeout in a matching rule should override the timeout send by the app.
@ddlr do the rules really match? So does the color changing apply?

[dddlr]

Sorry for late response.

notify-send -t 100 "blehp" does indeed timeout after 1 second. Not sure how I got 3 seconds before – maybe it’s because I switched to using the dunst-git AUR package after posting my comment? dunst --version now shows the version as v1.0.0-112-g23d8755

@knopwob Yeah, the different background colour is applied.

[quite]

For me, dunst git as of today lets the notification sit around for milliseconds rounded up to whole second(s) plus 1 second. As @knopwob lays it out.

[tsipinakis]

Can you still reproduce the issue on the current HEAD? It looks like it's working properly on my end.

[dddlr]

@tsipinakis The timeouts are still ignored on desktop notifications for Discord Canary 0.0.15 and Discord (Stable) 0.0.1. Dunst version is now v1.1.0-131-g1e735c6.

I’m curious as to what your .dunstrc has for it to work. The relevant parts of mine are still the same as above, but with this added somewhere between the [global] block and [discord_canary]. Discord uses the normal urgency level.

[urgency_low]
    background = "#222222"
    foreground = "#888888"
    timeout = 30

[urgency_normal]
    background = "#0073CC"
    foreground = "#ffffff"
    timeout = 30

[urgency_critical]
    background = "#d00000"
    foreground = "#ffffff"
    timeout = 30

[tsipinakis]

I meant that overriding timeouts with rules seems to be working when I tested it with dunstify. Since I don't use discord I'll need your help in debugging this. Can you post the following pieces of information while on a3cce0e? (Feel free to snip out anything sensitive obviously):

• Output of dunst -print while a discord notification goes through

• The contents of your config file

• The output of dbus-monitor while a notification goes through(be sure to wait until it times out so the NotificationClosed message is also caught)

[dddlr]

.config/dunst/.dunstrc - https://p.teknik.io/agyi3

dunst --version:

Dunst - A customizable and lightweight notification-daemon v1.1.0-132-ga3cce0e

dunst -print with receiving a direct message on Canary 0.0.15, where notifications disappear in approx 3 seconds. dbus-monitor output is here.

{
	appname: 'Discord Canary'
	summary: 'Croissant'
	body: 'this is a test message'
	icon: '(null)'
	raw_icon set: true
	category: 
	timeout: 30
	urgency: 1
	formatted: '<b>Croissant</b>
this is a test message'
	fg: #ffffff
	bg: #004400
	frame: #888888
	id: 1208
	actions:
	{
		 [default,View]
actions_dmenu: #View [Discord Canary]
	]
	script: (null)
}

---

For comparison, using dunstify -a "Discord Canary" -t 2 "Test message" - notification takes 30 seconds to disappear as intended. dbus-monitor output is here.

{
	appname: 'Discord Canary'
	summary: 'Test message'
	body: ''
	icon: 'info'
	raw_icon set: false
	category: 
	timeout: 30
	urgency: 1
	formatted: '<b>Test message</b>'
	fg: #ffffff
	bg: #004400
	frame: #888888
	id: 16
	script: (null)
}

In case you’re wondering, Croissant is the account I used to send the Discord direct message. I’m accessing the Croissant account from Chromium, which shouldn’t and doesn’t trigger dunst’s notifications.

I installed dunst via the AUR package.

[tsipinakis]

method call time=1485689566.406320 sender=:1.147 -> destination=:1.155 serial=41 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=CloseNotification
   uint32 1208
signal time=1485689566.407168 sender=:1.155 -> destination=:1.147 serial=7 path=/org/freedesktop/Notifications; interface=org.freedesktop.Notifications; member=NotificationClosed
   uint32 1208
   uint32 3

Looks like Discord is sending a CloseNotification command, I don't think this is an error on dunsts side.

[tsipinakis]

It's a long shot but looking over the notification spec again, looks like the persistence capability might affect the behaviour. I just pushed a new branch can you compile and see if that fixes it?

[dddlr]

No difference, unfortunately.

dunst --version output:
Dunst - A customizable and lightweight notification-daemon v1.1.0-133-g28cb7da

dunst -print output when receiving a direct message in Discord (similar to in my previous comment). dbus-monitor output is here.

{
	appname: 'Discord Canary'
	summary: 'Croissant'
	body: 'this is a test message'
	icon: '(null)'
	raw_icon set: true
	category: 
	timeout: 30
	urgency: 1
	formatted: '<b>Croissant</b>
this is a test message'
	fg: #ffffff
	bg: #004400
	frame: #888888
	id: 1215
	actions:
	{
		 [default,View]
actions_dmenu: #View [Discord Canary]
	]
	script: (null)
}

Looks like Discord is sending a CloseNotification command, I don't think this is an error on dunsts side.

Hmm… I’ll ask the Discord folks and see what they can do.

[tsipinakis]

I'm closing this since it's not a problem with dunst itself. It might be worth updating this to inform others experiencing this issue when you get a response from the Discord team(or a link to the relevant bug on the Discord bug tracker, if any).

[cipriancraciun]

Although I do understand why some applications would send CloseNotification (for example to hide a notification that doesn't apply anymore), for some other applications (like for example email clients like Gmail Desktop) this is just annoying.

Therefore (though I understand this is not dunst's fault) it would be wonderful if one had a solution to just ignore the CloseNotification signal, at least for select clients.

[cipriancraciun]

For those interested the following simple patch makes dunst just ignore the CloseNotification signal (i.e. just comment out the call to queues_notification_close_id inside dbus_cb_CloseNotification):

diff --git i/src/dbus.c w/src/dbus.c
index 741a1c5..03923d4 100644
--- i/src/dbus.c
+++ w/src/dbus.c
@@ -328,21 +328,21 @@ static void dbus_cb_Notify(
 }
 
 static void dbus_cb_CloseNotification(
                 GDBusConnection *connection,
                 const gchar *sender,
                 GVariant *parameters,
                 GDBusMethodInvocation *invocation)
 {
         guint32 id;
         g_variant_get(parameters, "(u)", &id);
-        queues_notification_close_id(id, REASON_SIG);
+        // queues_notification_close_id(id, REASON_SIG);
         wake_up();
         g_dbus_method_invocation_return_value(invocation, NULL);
         g_dbus_connection_flush(connection, NULL, NULL, NULL);
 }
 
 static void dbus_cb_GetServerInformation(
                 GDBusConnection *connection,
                 const gchar *sender,
                 GVariant *parameters,
                 GDBusMethodInvocation *invocation)

[resolritter]

Worth mentioning that #732 introduced the ignore_dbusclose section, which might obsolete the need for #276 (comment) 's patch

[juliohm1978]

Hi guys, this seems a bit controversial, since ignore_dbusclose does not resolve the issue entirely.

I'm running into this issue and trying to understand why exactly dunst is unable to ignore some application timeouts.

I'm not an expert on the notification spec, but, like other people around, I feel that your notification manager should be able to override the timeout given by applications when matched by its own rule.

I managed to find the exact line of code that contradicts this logic in src/notification.c.

https://github.com/dunst-project/dunst/blob/v1.9.2/src/notification.c

Scroll down to the last few lines of the notification_init() function. The comment seems quite obvious, as it gives priority to the timeout value sent by the application. You can change this logic with the following:

        if (n->dbus_timeout >= 0 && n->timeout <= 0)
                n->timeout = n->dbus_timeout;

That's it... this allows dunst to override the notification timeout it receives from dbus. That's an easy patch. I hope this helps anyone else that thinks the same way about notification timeouts.