Finish startup sequence when the launchee exits too early
[Moved from gnome-shell#267 (closed)]
I think I might have found an issue with how some of the bits related to the Startup Notification spec  are implemented, since there seems to be a problem when dealing with single-instance applications shipping multiple .desktop files that run the same executable file, such as gnome-control-center.
As per the Startup Notification Spec, when an application declares
StartupNotify=true in its desktop file, the launcher (e.g. the shell) will initiate the startup process, expecting the launchee to finish it with a "remove" X message once it's ready, unless there's a failure launching it.
The problem I found with the particular case of gnome-control-center can be seen following these steps:
Open gnome-control-center and leave it open, making sure that g-c-c's Name and Icon are shown in the top panel (right of "Activities")
From GNOME Shell's top panel, open the system indicators popup and open any panel in the control panel from there (e.g. "Account Settings")
Look at the name & icon in the top panel while this second panel is loading --> you'll see how it changes from "Settings" to the name & icon of the panel being loaded (e.g. "Users") for some seconds, and a spinner is shown
Hovering over g-c-c's window shows the spinning cursor as well for a few seconds, then it finally changes back to the arrow and the panel is shown.
What is going on?
The problem here is that these panel-specific desktop files declare
StartupNotify=true, which makes the shell (as per a call to
g_desktop_app_info_launch_uris_with_spawn()) to initiate the startup sequence when trying to open the desired panel from g-c-c, as that's inline with the spec in . However, since g-c-c is a single-instance application and the
Exec lines in all those panel-specific desktop files point to the
gnome-control-center binary, what that new process does as soon as it's run is to realize that another main instance is running, hand over the parameters passed to it, and exit gracefully without an exit code.
However, at this point the startup sequence was already started and, as a result, it was expected that the launchee would eventually send a "remove" X message as per the spec. But that message would be only sent once the "new" application's top level window gets mapped (from
gdk_x11_display_notify_startup_complete()), and since that second process exits early before mapping any window, that message is never sent... resulting in the whole sequence to keep alive until it's ended on a timeout.
In summary, this means that the shell will believe for a while (until the process is ended on a timeout) that an actual second application is starting up, with its own name and icon, since a different desktop file other than gnome-control-center.desktop was used for the launch... which is really confusing.
Reading the section "Launchee failures" from the spec in , it says: "The launcher process is responsible for detecting launchee failures such as a crash and should end the launch sequence in such case. In case launchee fails to end the launch sequence, clients should treat the launch sequence as ended withing a reasonable time.
The problem here is that there's not really a failure in the launchee, which exits gracefully after handing over the parameters, which I believe is a bug somewhere: IMHO, it should be detected when this kind of situation happens and make sure that the startup sequence is correctly finished in that case.
I initially filed this bug against GLib since that's where the whole process gets initiated via a call to
g_app_launch_context_get_startup_notify_id(), and then I moved it to GNOME Shell before realizing (thanks to @cosimoc and @ebassi) that this could actually be fixed in GtkApplication, so moving it to GTK now...