Launcher - Quit does not actually quit applications

Reported by Dylan McCall on 2010-08-11
184
This bug affects 49 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Medium
John Lea
One Hundred Papercuts
Medium
Unassigned
Unity
Medium
Unassigned
unity (Ubuntu)
Medium
Unassigned

Bug Description

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.

description: updated
Neil J. Patel (njpatel) wrote :

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.

Changed in unity:
assignee: nobody → Gord Allott (gordallott)
importance: Undecided → Low
milestone: none → 2010-09-02
status: New → Opinion
Neil J. Patel (njpatel) on 2010-09-05
Changed in unity:
milestone: 2010-09-02 → 2010-09-16
Neil J. Patel (njpatel) on 2010-09-16
Changed in unity:
milestone: 2010-09-16 → backlog
David Barth (dbarth) on 2010-11-08
Changed in unity:
milestone: backlog → none
assignee: Gord Allott (gordallott) → nobody

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

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.

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

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

Changed in unity:
milestone: none → 3.8.12
Paul Sladen (sladen) wrote :

Mark: Process level kill(2) !!!

John Lea (johnlea) on 2011-04-21
description: updated
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
importance: Undecided → Low
status: New → Fix Committed
Omer Akram (om26er) on 2011-04-22
Changed in unity:
status: Opinion → Confirmed
David Barth (dbarth) wrote :

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.

Changed in unity:
milestone: 3.8.12 → backlog
Didier Roche (didrocks) on 2011-04-26
Changed in unity (Ubuntu):
status: New → Confirmed
Changed in unity (Ubuntu):
importance: Undecided → Low
John Lea (johnlea) on 2011-10-18
tags: added: udo
John Lea (johnlea) on 2011-10-18
tags: added: udp
Changed in ayatana-design:
status: Fix Committed → Triaged
John Lea (johnlea) on 2011-11-03
Changed in unity:
assignee: nobody → Jason Smith (jassmith)
Changed in ayatana-design:
status: Triaged → Fix Committed
John Lea (johnlea) on 2012-01-11
Changed in ayatana-design:
importance: Low → High
frizzle21 (frederik-nnaji) wrote :

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) wrote :

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

Tormod Hellen (tormod-hellen) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Marius B. Kotsbak (mariusko) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

John Lea (johnlea) on 2012-08-29
summary: - Quit does not actually quit applications
+ Launcher - Quit does not actually quit applications

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.

John Lea (johnlea) on 2012-10-04
Changed in unity:
status: Confirmed → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
Changed in unity:
importance: Low → Medium
assignee: Jason Smith (jassmith) → nobody
Changed in unity (Ubuntu):
importance: Low → Medium
Changed in ayatana-design:
importance: High → Medium
Dario Ruellan (druellan) wrote :

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!

Chris Wilson (notgary) on 2012-11-01
Changed in hundredpapercuts:
status: New → Triaged
milestone: none → raring-round-3
assignee: nobody → Papercuts Ninja (papercuts-ninja)
importance: Undecided → Medium
Chris Wilson (notgary) on 2013-05-27
Changed in hundredpapercuts:
milestone: none → papercuts-s-unity
Kai Mast (kai-mast) on 2013-12-31
tags: added: trusty
Changed in hundredpapercuts:
assignee: Papercuts Ninjas (papercuts-ninja) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers