Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong order of ActionInvoked and NotificationClosed signals emitting #3836

Open
librolibro opened this issue Aug 9, 2023 · 0 comments
Open
Milestone

Comments

@librolibro
Copy link

librolibro commented Aug 9, 2023

Output of awesome --version:

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

  1. Create notification with one or more actions
  2. Open D-Bus monitor to see when exactly ActionInvoked and NotificationClosed signals were emitted
  3. 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)

Actual result:

~ busctl --user -- call org.freedesktop.Notifications \
    /org/freedesktop/Notifications org.freedesktop.Notifications \
    Notify susssasa{sv}i \
    "" \
    0 \
    "" \
    "Test title" \
    "Test message" \
    2 "edit-copy" "Test action" \
    1 action-icons b true \
    0 && busctl --user --json=short --match="type='signal',interface='org.freedesktop.Notifications'" monitor
u 62
Monitoring bus message stream.
{"type":"signal","endian":"l","flags":1,"version":1,"cookie":220,"timestamp-realtime":1691618601401985,"sender":":1.7","path":"/org/freedesktop/Notifications","interface":"org.freedesktop.Notifications","member":"NotificationClosed","payload":{"type":"uu","data":[62,2]}}
{"type":"signal","endian":"l","flags":1,"version":1,"cookie":221,"timestamp-realtime":1691618601402120,"sender":":1.7","path":"/org/freedesktop/Notifications","interface":"org.freedesktop.Notifications","member":"ActionInvoked","payload":{"type":"us","data":[62,"edit-copy"]}}
^C

Expected result:

~ busctl --user -- call org.freedesktop.Notifications \
    /org/freedesktop/Notifications org.freedesktop.Notifications \
    Notify susssasa{sv}i \
    "" \
    0 \
    "" \
    "Test title" \
    "Test message" \
    2 "edit-copy" "Test action" \
    1 action-icons b true \
    0 && busctl --user --json=short --match="type='signal',interface='org.freedesktop.Notifications'" monitor
u 60
Monitoring bus message stream.
{"type":"signal","endian":"l","flags":1,"version":1,"cookie":212,"timestamp-realtime":1691618335769427,"sender":":1.7","path":"/org/freedesktop/Notifications","interface":"org.freedesktop.Notifications","member":"ActionInvoked","payload":{"type":"us","data":[60,"edit-copy"]}}
{"type":"signal","endian":"l","flags":1,"version":1,"cookie":213,"timestamp-realtime":1691618335769487,"sender":":1.7","path":"/org/freedesktop/Notifications","interface":"org.freedesktop.Notifications","member":"NotificationClosed","payload":{"type":"uu","data":[60,2]}}
^C

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).

@Elv13 Elv13 added this to the v4.4 milestone Jan 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants