You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
awesome v4.3-1606-g0e5fc457-dirty (Too long)
• Compiled against Lua 5.1.4 (running with LuaJIT 2.1.0-beta3)
• API level: 4
• D-Bus support: yes
• xcb-errors support: no
• execinfo support: yes
• xcb-randr version: 1.6
• LGI version: 0.9.2
• Transparency enabled: yes
• Custom search paths: no
How to reproduce the issue:
Note: It will reproduce (at least for me) even with the default config
Create notification with one or more actions
Open D-Bus monitor to see when exactly ActionInvoked and NotificationClosed signals were emitted
Click the action (notification will close after clicking since there's no resident hint)
#!/bin/sh
# Reproducible example
# AFAIK *busctl* is part of the systemd
busctl --user -- call org.freedesktop.Notifications \
/org/freedesktop/Notifications org.freedesktop.Notifications \
Notify susssasa{sv}i \
"" \
0 \
"" \
"Test title" \
"Test message" \
"$#" "$@" \
1 action-icons b true \
0 && busctl --user --json=short --match="type='signal',interface='org.freedesktop.Notifications'" monitor
# busctl call will print *u MESSAGE_ID* (u is uint32 and MESSAGE_ID is the value)
# busctl monitor will output any call of method for org.freedesktop.Notifications interface in JSON format
# (for ActionInvoked and NotificationClosed methods the result JSON will contain "payload" dictionary field
# with "data" list field - first element should be the same MESSAGE_ID)
As you can see, NotificationClosed signal is emitting before the ActionInvoked one - and this happens quite often. I haven't found any source that would confirm that this behavior is acceptable (for example, XDG notification spec contains only method dsecriptions).
The text was updated successfully, but these errors were encountered:
Output of
awesome --version
:How to reproduce the issue:
Note: It will reproduce (at least for me) even with the default config
Actual result:
Expected result:
As you can see, NotificationClosed signal is emitting before the ActionInvoked one - and this happens quite often. I haven't found any source that would confirm that this behavior is acceptable (for example, XDG notification spec contains only method dsecriptions).
The text was updated successfully, but these errors were encountered: