Launcher - Quit does not actually quit applications

[Dylan McCall]

This bug report is about the Quit option listed under the context menu for all running programs in the Unity shell.

I will start with examples:

 * Choosing Quit with Rhythmbox will close the main window, but the process continues to run. (The indicator provides a duplicate Quit option that does the right thing, but even if that was merged with the existing Quit option it would not be a sustainable solution).
 * I have Dropbox running in the background, and Unity has cleverly added it to the launcher panel with its indicator menu available. Choosing Quit does nothing, because Dropbox is a daemon with no toplevel windows.

From the looks of it, Unity is just closing every window attached to the application's process and wrongly assumes this will cause it to quit. In fact, that often does not happen, and it is a very strange, semantically unclear behaviour.

Desired solution:
- Do the right thing by sending the _process_ a QUIT signal. If a GUI app doesn't handle that signal properly, that is its problem and it should be fixed there.

[Neil J. Patel (njpatel)]

This makes sense to me. We need to be careful about quicklist options when there are no windows attached to the application, but we also need to make sure we don't leave users confused as to why they can't get rid of an icon.

[Mark Shuttleworth (sabdfl)]

From a design point of view, I think we're happy to hit 11.04 with this
behaviour unchanged. Apps that have special semantics for "really quit"
can expose that in their menu's. We can revisit for 11.10.

Mark

[Jane Silber (silbs)]

Personally, I find the current behaviour troublesome. For instance, I select Quit from the launcher for Pidgin, and it closes windows but leaves processes running (and then people think I am around when I am not). And when the windows are gone, there is no way to know that Pidgin is still running, since it has been removed from panel (in previous Ubuntu releases it left an icon in the systray and you could quit from there, but now it is hidden out of sight in the messaging menu).

Perhaps Pidgin is a particularly problemmatic case of the designed behaviour, because it is also running up against the fact that it has been banned from the panel. But the combination means that we have behaviour that doesn't work at a pretty basic level. (I.e., when the user says they want to Quit the app, it doesn't do so, although every indication to the user is that it has quit).

I suspect that the common case is that when a user (particularly a non-power user) selects quit from the Launcher, they want to actually quit. I suspect that the intention of "close the windows but leaves the daemon or background processes running" is something of a corner case, or at least limited to a small number of apps that could be special-cased.

[Mark Shuttleworth (sabdfl)]

Do we have a way to tell the app to quit other than to tell each of its
windows to close?

[Didier Roche-Tolomelli (didrocks)]

(added the milestone for tracking). Seems linked to the general issue we discussed during the release with daemons like tomboy

[Paul Sladen (sladen)]

Mark: Process level kill(2) !!!

[David Barth (dbarth)]

It's not as simple as sending a kill to the associated process. Sometimes we do have a direct mapping between a window or a set of windows, and an associated PID. But sometimes not: chromium is such a case where chrome windows, tabs and renderers processes are grouped totally differently. And sometimes there are service processes with no windows anymore, and.

The scope of design for the launcher excluded the case of service applications, and as part of that we have implemented the best solution to the problem we could design: closing windows to reuse a known code paths in applications, ie reproducing what users do with the close buttons.

Introducing a change to send a close signal at this stage is very dangerous: it can work on simple cases, where the xid - pid mapping is simple and known. It will break for the non trivial cases, and we can't be sure of the ramifications of this change in just 1 week of testing (for a 0day-SRU).

An SRU could be provided later after the release, but then it will require a serious exception to the SRU definition, as it will introduce a change in the behavior of the product.

[frizzle21 (frederik-nnaji)]

if it doesn't "quit", don't call it quit.
That's the law of correspondence.

Please simply correct the label to "close" wherever you know that it doesn't make the process tree of an application's pid quit.
This is already known to be valid for the quicklist "quit" entries of Rhythmbox, Empathy and Transmission.

It is clearly wrong to afford a button labeled "Quit", well knowing that it will NOT make anything quit. We're actually cheating the user, some people consider this a security issue, some might consider it an intrusion.
This is trivial, so it needs to be fixed wherever reported.

Analysing the dependency tree of a pid together with its associated frontend application and window set is a whole other task, which has nothing to do with labelling a button or list item correctly.

[frizzle21 (frederik-nnaji)]

added bug report for rhythmbox specifically:
https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/966885

[Tormod Hellen (tormod-hellen)]

If the user presses a "quit" button or the "shut down" button and the app does not really quit (and perhaps prevents the OS from shutting down) it's windows should be closed and it's processes killed.

[florin (florin-arjocu)]

It is not a Rhytmbox specific bug. In the last days I get it for Skype, Pidgin, Teamviewer in Ubuntu 12.04.

[florin (florin-arjocu)]

I must add more data: I am in the position of not being able to close Skype. I X-ed the window and I have no way to get back to Skype now, but I get notifications when people get online, so it is running. Exactly the same with Teamviewer7.

[florin (florin-arjocu)]

See these 2 recordings how I cannot quit Teamviewer neither by using Quit from launcher, nor by using the X (only the windows are closed, the processes are still running):

Launcher quit:
http://www.youtube.com/watch?v=tMHO93abLdo&feature=youtu.be

Using X to quit program:
http://www.youtube.com/watch?v=6WQsxVZdS2A&feature=youtu.be

I must use Kill to properly stop it.

[Marius B. Kotsbak (mariusko)]

I guess Teamviewer is supposed to be like that, and you can close it with the icon up in the right corner you cliked on in the video. But probably the unity menu on the left kill it completely.

[florin (florin-arjocu)]

There is no icon in the top right corner, that is from the recording software.

[Marius B. Kotsbak (mariusko)]

florin: it seems like you are using the windows version through wine (extention ".exe"). There is a Linux version available: https://www.teamviewer.com/no/download/index.aspx (Debian, Ubuntu). Have you tried it?

[florin (florin-arjocu)]

Yes, this is it :) Just like Picasa for linux, Teamviewer also has a "linux version" running actually in a self contained wine.

[Marius B. Kotsbak (mariusko)]

I just tried it in KDE, and could not reproduce the problem with getting rid of the process when using the X window button.

[florin (florin-arjocu)]

X does not close the process. I just tried it again and it is exactly the same with Skype. I cannot close skype neither by X or by Quit form laucher. I have no idea how to do more debugging, if you want I can allow a remote connection to my computer and you can see it for yourself.

[Marius B. Kotsbak (mariusko)]

Teamviewer and Skype are different, as Skype is supposed to not quit when the window is closed, it stays running with its tray icon.

[florin (florin-arjocu)]

So I shoudl report them to Wine/Teamviewer/Skype developers as I don't get the icon in top right area (in Windows it would have been in System Tray Area)?

[Edward Donovan (edward.donovan)]

Firefox is a good case for this potential fix, too. If you have more than one window open, normal quitting will save your session for next time. Close-every-window, from the quicklist Quit, leaves the last window that happens to be closed as your Firefox session on quit. The rest, you closed, as far as Firefox knows.

(Another level of complication: I sometimes have multiple firefox processes from different profiles open at once. bamf groups them as one. But asking it to see the difference may be a tall order. I'm not gonna pursue that one for now.)

Thanks.

[Dario Ruellan (druellan)]

Hi John.
We're discussing a similar bug about the "quit" implementation on Rhythmbox as part of the Paper Cuts "R" Cycle: bug #875002
Since apparently there is a solution already commited to this bug, can you have a look and give us some input? Perhaps we're discussing something already fixed or invalid.
Thanks!

[Marco Trevisan (Treviño) (3v1n0)]

In order to get this fixed you can provide a custom desktop action called "quit" for the affected app. This will override the official action.

[Tim Hollmann (3-ich)]

This patch adds a "Stop & Quit" option to Rhythmboxs launchbar icon, triggering "rhythmbox-client --quit"

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "xenial_rhythmbox_stopQuit" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Didier Roche-Tolomelli (didrocks)]

The patch looks excellent!

Just a last nitpick: you did see that all other patches in debian/patches ends with .patch, mind renaming yours to end with a .patch as well? (and don't forget to do the same change in debian/patches/series).

Then, just regenerate a debdiff and we should be good to go!

[Didier Roche-Tolomelli (didrocks)]

And here we go! I've uploaded it (after some minor modifications like referencing this bug report so that it can be closed automatically) and a patch renaming. Otherwise, everything's good!

You can find a reference to it (and see it building) at https://launchpad.net/ubuntu/+source/rhythmbox/3.2.1-1ubuntu7. You can even look at the diff if you are interested.

Nice work! Thanks again ;)

[Launchpad Janitor (janitor)]

This bug was fixed in the package rhythmbox - 3.2.1-1ubuntu7

---------------
rhythmbox (3.2.1-1ubuntu7) xenial; urgency=medium

  * 08_stop_quit.patch:
    - Added a "Stop & Quit"-option to the quickmenu (via .desktop)
      (LP: #616447)

 -- Tim Hollmann <email address hidden> Thu, 24 Dec 2015 10:20:24 +0100