Created attachment 184434 [details]
Bustle, dbus.log

After some debugging I noticed following:

gdbus monitor output:

Monitoring signals from all objects owned by org.freedesktop.Notifications
The name org.freedesktop.Notifications is owned by :1.17
/org/freedesktop/Notifications: org.freedesktop.Notifications.ActionInvoked (uint32 55, 'details')
/org/freedesktop/Notifications: org.freedesktop.Notifications.NotificationClosed (uint32 55, uint32 3)
/org/freedesktop/Notifications: org.freedesktop.Notifications.NotificationClosed (uint32 56, uint32 2)

dbus log:

(attached)

Steps to reproduce debug output:

1. Start a file/folder operation
2. Close the file operations dialogue
 -> (dbus.log:111)
3. Click "Show details"
 -> (dbus.log:114-116, gdbus:3-4)
4. Close all nautilus windows
 -> (dbus.log:120)

However NotificationClosed (gdbus:5) is emitted immediately without any user interaction. (This contradicts the reason: 2 - "The notification was dismissed by the user.", http://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html) 

I think, that this UX bug isn't caused by nautilus but the message-tray/notification-service of gnome-shell.

It also looks like the notification is not dispayed centered at the bottom when it's fired.

To sum up the discussion from #gnome-shell:

- gnome-shell only tracks the lifecycle of windows, not of applications.
- a new mechanism is required to catch these cases (e.g. watching the unique name of the application)
- source hint: http://git.gnome.org/browse/gnome-shell/tree/js/ui/notificationDaemon.js#n527

Created attachment 191424 [details] [review]
NotificationDaemon: remove source if notification sender is removed from DBus

We don't want sources that are no longer associated with a running application to stick around in the message tray.
Message tray sources were removed when the associated application’s state changed to Shell.AppState.STOPPED . This caused sources for applications that were
still running, but did not have any open windows to be removed. Instead, we
should use the notification’s sender removal from DBus as an indicator for when to remove the associate source from the message tray.

The above patch looks good to me, but since I helped writing it, it would be good if someone else, like Dan or Florian, reviewed it.

My only nitpick is to add an empty line after the first sentence in the commit message and to add line breaks in the commit message, so that it ends up being better formatted (I can do that when committing it).

One independent issue that this patch brought to light is an inconsistent behavior of the Nautilus notifications. I have discussed it with Cosimo and we'll work on figuring out how to fix it, but it shouldn't be blocking this patch.

The notification displayed has either one of the following behaviors:
a) Shows a Nautilus “file cabinet” icon and uses “Files” title for source; does not pop up a new notification, but adds it directly to the message tray instead
b) Shows a default “light bulb” icon and uses “nautilus” title for source; pops up a new notification in addition to adding it to the message tray

The reason this happens is that there is a race condition with Nautilus closing the window and sending the notification. If the window is still known to the Shell.WindowTracker, the application icon and name are retrieved, which are the “file cabinet” icon and the “Files” string. In addition, the window tracker still considers the Nautilus window to be focused, so it suppresses showing the new notification, as new notifications from applications with focused windows are not shown. However, if the window is no longer known to the Shell.WindowTracker, the default “light bulb” icon that is used for the notification and the notification’s appName that is passed in as “nautilus” are used for the source’s icon and title respectively.

Nautilus doesn’t send an icon or “icon-data” or “icon-path” hints in the notification, so the default “light bulb” icon is used.

Comment on attachment 191424 [details] [review]
NotificationDaemon: remove source if notification sender is removed from DBus

Looks good. Test to make sure that it doesn't break trayicons though, if you haven't yet.

>+            // TODO: dbus-glib implementation of watch_name() doesnât return an id to be used for
>+            // unwatch_name() or implement unwatch_name(), however when we move to using GDBus implementation,
>+            // we should save the id here and call unwatch_name() with it in destroy().
>+            // Moving to GDBus is the work in progress: https://bugzilla.gnome.org/show_bug.cgi?id=648651
>+            // and https://bugzilla.gnome.org/show_bug.cgi?id=622921 .

It would be good to add a patch to the GDBus bug to fix this (which can then get squashed into the existing patch next time they rebase). Or at least, add a comment there pointing out that you've added a new dbus-glib call that they'll need to deal with.

Comment on attachment 191424 [details] [review]
NotificationDaemon: remove source if notification sender is removed from DBus

Checked that tray icons still work and added a comment about this DBus usage to the GDBus migration bug.

Leaving this bug open to deal with the inconsistent behavior of the Nautilus notifications.

This patch broke the use of notify-send, since it exits immediately after sending the notification.

(In reply to comment #5)
> Message tray sources were removed when the associated application’s state
> changed to Shell.AppState.STOPPED . This caused sources for applications that
> were
> still running, but did not have any open windows to be removed.

I think this is the real bug. "Has no mapped toplevel windows" is not the right condition to use to decide that an app has exited.

Pushed http://git.gnome.org/browse/gnome-shell/commit/?id=0366e320af579d7c2172c4430c97bf336f6b4b09

It checks if this.app is set when removing the source to avoid removing "notify-send" sources, senders of which are removed from DBus immediately.

This has been fixed for a while.